About Me• Benjamin J. Steinhauser• SharePoint Solutions Developer• B&R Business Solutions• BSCS, MSCS; MCP, MCTS• 10+ years as ASP.NET Application Developer• SharePoint Developer since 2001 • All versions: SharePoint Portal Server 2001, Microsoft SharePoint 2003, Microsoft Office SharePoint Server 2007, Microsoft SharePoint Server 2010, and SP2013 Preview!• Creator of Open Source CodePlex Projects • SPCAMLQueryHelper • SPClippy • SPjQuerify • SPEasyBranding • SPClaimsBasedAuthExamples• Presenter at SP User Groups and SharePoint Saturday Events
SP Authentication Methods Classic Mode Claims BasedAuthentication Authentication Traditional Windows Authentication New for SP2010! Uses Windows Identity Foundation (WIF) NTLM, Kerberos, Basic Everything is tokens, claims, identity provider, security token service (-) No more FBA available when using Classic! (+) All auth types are available (+) Less confusing for simple Farms (-) not simple!
Supported Authentication Methods Windows • NTLM, Kerberos, Basic FBA • LDAP, MS SQL Server • Or, custom 3rd party ASP.NET membership and role providers SAML token-based Auth. • Uses Active Directory Federation Services (AD FS) 2.0 • 3rd party identity provider
What are Claims?• SharePoint Server 2010 automatically changes all accounts to claims identities, resulting in a claims token for each user • Claims Identifiers: • Windows: i:0#.w|domainsAMAccountName • FBA: i:0#.f|customdbusersmp|user1• Identity is stored in a security Token • Contains one or more claims about the user • Claims are meta-data for the user• SharePoint Server running in Claims Mode Authentication utilizes a Security Token Service (STS)• STS acts as an authentication gateway to SharePoint Server, supports access • Windows Integrated Authentication • Form Based Authentication • Trusted Claims Providers (TRUST).
Forms-Based Authentication Claims• SharePoint Server redirects the client to a login page• Page authenticates the client using the ASP.NET Membership provider• Identity is created • SPClaimsUtility.AuthenticateFormsUser()• SharePoint Server will then translate this identity to a claims identity object.
Pre-SP2010 FBA Login Page User enters Username and Password, clicks “Login” Codebehind calls MemberShip.ValidateUser() User is Auth, Redirect: FormsAuthentication.RedirectFromLoginPage()
SP2010 FBA Login Page User enters Username and Password, clicks “Login” Codebehind calls SPClaimsUtility.AuthenticateFormsUser() STS executes code to Validate user using Membership Provider User is Auth, Redirect
SP2010 Mixed Mode• Web Application that uses Claims Based Authentication can support multiple modes of authentication simultaneously • Single login page for both Windows and FBA users • ***Windows Identity and FBA Identity are 2 different identities, even if the actual identity in the background is the same***
Mixed Mode Pros/ConsCons• No more transparent Auth. in an Intranet Environment• Sign in required, custom solution available here: http://www.orbitone.com/en/blog/archive/2010/06/23/sharepoint-2010- mixed-authentication-automatic-login.aspx• Tricky to build custom login pages for Mixed Mode• Always presented with choice for users (when there really is no choice since have only 1 identity), can confuse non-technical usersPros• Only one web.config file to make changes in (per server)• Email alerts sent by SharePoint have only 1 url to manage• Sending links to documents or pages (manually or maybe using quick links) have only 1 url
DEMO #1: Mixed Mode• Default Zone• http://mixed.spdevmutts.com• Uses Windows Authentication• Uses FBA, providers: “Nice…” • Membership: CustomDbUsersMP • uses custom SQL Server table: CustomDbUsersLists• No anonymous access• No custom login page
FOCUS: FBA in SP2010 Role ProviderMembership Provider (Optional) Custom Login Web.config Page/Web Part Modifications
CODE: Membership Provider• Membership Provider (REQUIRED) • 2 built-in OOB Providers: • LDAP/AD: ActiveDirectoryMembershipProvider • MSSQL: System.Web.Security.SqlMembershipProvider • Custom: • .NET Class inheriting MembershipProvider base class • Must override certain functions for SharePoint: • FindUsersByEmail, FindUsersByEmail, GetAllUsers, GetUser (2 functions), GetUserNameByEmail, ValidateUser • Can connect to any identity repository available that .NET code can access (ex. Oracle, Facebook, Twitter, SQL Server, XML File) • Add .NET class to GAC or local web application BIN folder • Can be deployed as a solution (WSP) easily to either GAC or BIN
CODE: Role Provider• Role Provider (OPTIONAL): • 1 Built-in OOB Provider: • MSSQL: System.Web.Security.SqlRoleProvider • LDAP/AD Role Provider available at codeproject.com • Custom: • .NET Class inheriting RoleProvider base class • Must override certain functions for SharePoint: • GetUsersInRole, IsUserInRole, GetAllRoles, FindUsersInRole, GetRolesForUser, R oleExists • Can connect to any identity repository available that .NET code can access (ex. Oracle, Facebook, Twitter, SQL Server, XML File) • Add .NET class to GAC or local web application BIN folder • Can be deployed as a solution (WSP) easily to either GAC or BIN • ***Dynamic roles can be created that users can slide in and out in real time without manual intervention by admin (ex. admin role based on a DB field)
XML: Web.config changes• 3 web.config files (at a minimum) to be changed: • Central Administration (CA) • PeoplePickerWildcard, ConnectionStrings, Appsettings, Membership, RoleManager • Security Token Service (STS) • ConnectionStrings, Appsettings, Membership, RoleManager • Web Application (WA) • PeoplePickerWildcard, ConnectionStrings, Appsettings, Membership, RoleManager
Adding User Policy• CA web.config was updated so FBA users can be added as: • Site Collection administrator • or, “Full Control” user policy to manage FBA site• This is necessary for the first (admin) FBA user to login to SharePoint Site and assign other permissions
Typical Login Scenarios• Windows Authentication: • Windows Popup• FBA: • OOB Login Page (built-in) • Custom Login Page • Anonymous access not required if login page does not use SharePoint Master Page or minimal master page • Custom Login Web Part (SharePoint Web Part or Visual Web Part) • Added to a web part page • Anonymous access required to get to web part page• Benefits of using Custom Login: • can take over the login process, and extend OOB with features like: • adding a CAPTCHA • any custom code action/event (logging, automation, syncing, etc.) • custom redirecting (targeted content, 3rd party identity management) • Site Agreements, Information Policies: agreements, privacy, EULA, etc. • Multi-Factor authentication: using SMS, tokens, etc.
DEMO #2: FBA Secure• Internet Zone• http://fbasecure.spdevmutts.com• Uses FBA only, providers: • Membership: CustomDbUsersMP• No anonymous access “Cool!”• Custom login page • includes a mandatory “policy agreement” before logging in
DEMO #3: FBA Anonymous• Custom Zone• http://fbaanon.spdevmutts.com• Uses FBA only, providers: • Membership: CustomDbUsersMP• Anonymous access enabled “Wow!” • (in CA WA settings – 2 places, and WA site settings)• Custom login page • Custom login web part • added to a standard SharePoint web part page • includes a mandatory “policy agreement” before logging in
Identities in the Cloud!• 3rd party Identity Management• Decentralized/Distributed Authentication• “One identity to rule them all”• Common Internet Implementations: • Facebook, Google, OpenID, Twitter• OAuth: An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.• Identity is known (username, email, etc.)• Password is not
OAuth Pros/ConsPROS• Accelerate signup process: users can use existing identities, less reluctant to create new identity• Reduce Frustration Associated with Maintaining Multiple Usernames and Passwords• Gain Greater Control Over Your Online Identity (You control how much personal information you choose to share)• It’s the Cloud!CONS• No repository of users that is searchable, complicates things in SP• User Profile Synchronization is not supported: no repository of users to sync, custom solutions will need to be built• Membership provider will be Validating User without a password?!?
Twitter API• http://dev.twitter.com• Create a new “application”• Create an access token• Take note of consumer key and secret (needed by code to sign OAuth requests)• Configure access token rights (read/write)• Need a callback url (even though your app specifies its own)
DEMO #4: FBA and Twitter• Extranet Zone• http://twitter.spdevmutts.com• Uses FBA only, providers: • Membership: CustomTwitterMProvider • Resolves anything entered in PeoplePicker “OMG!”• No anonymous access• Custom login page • redirects to Twitter to authenticate and authorize• Custom Web Part for Tweets!
Membership.ValidateUser• How to implement the ValidateUser(username, password) without a Password? • OPTION 1: blank password/skip password evaluation: • Can a user login using another web application’s login page? what about web services, REST, Client OM, etc? • OPTION 2: username + salt + encryption • Custom Login page calls: 1. SPClaimsUtility.AuthenticateFormsUser(url, username, password) 2. STS calls Membership.ValidateUser(username, password) 3. Password = Encrypt(username + salt) • Membership.ValidateUser(username, password): • Recreate password sent to function, by applying same algorithm to username • compare passwords, should be same
Putting it together• Visual Studio 2010: • Empty SharePoint 2010 Project – FBAAddOns • Providers • in GAC • Login Pages • in layouts • Web Parts • Feature driven • Helper classes • in GAC
Future Considerations• SPClaims Ticket Expiration (lasts a long time by default)• User Profiles: • Either, custom sync timer job or integration with User Profile Sync Service Application • or, handle on login• Client application integration (MS Office 2010) • custom login page IS supported in rich clients• Configuring Search, Alternate Access Mappings• Extending this to other Providers: • Facebook, OpenID, CAS• SHAREPOINT 2013 PREVIEW APPS (OAuth 2.0!)