SharePoint 2010 Custom Authentication Providers


Published on

Presented 1/7/2012, SharePoint Saturday Virginia Beach, by Benjamin Steinhauser.

Using SharePoint 2010 Claims Based Authentication to extend the out-of-the-box functionality to support multiple authentication providers. This includes custom FBA authentication using default SQL authentication, a custom membership provider using a simple database table containing user accounts. Also, a custom membership provider using OpenID to authenticate remote users will be demonstrated, showing how SharePoint can leverage newer paradigms with user identities on the web. Additionally, intranet and internet login concepts will be covered to handle anonymous, semi-anonymous and protected web sites. Examples will be shown for each of the concepts demonstrated, keeping the presentation interactive and showing the pro/cons of each concept.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • classic is still OK
  • windows accounts, fba accounts, converted to claimssecurity tokens passed around containing claims (user identities)claims contain user info (meta-data)STS is the gateway for managing, resolving claims
  • SKIP
  • provider not needed if using exiting providermssql, ldap/ad
  • basically, adding FBA site admin
  • SKIP
  • show: 881 sitelogin using AD (administrator, bsteinhauser)login using FBA (user1)show CustomDBUsers App (L2S)show code: membership/role providers
  • show: 882 sitelogin using FBA (user2 first, then user1)show code: role provider, “DynamicAdmins” groupshow code: custom login page
  • show: 883 siteopen site, then login using FBA (user1)show anon settings: CA WA, WA Site Settingsshow login web part, added to web part pageshow code: custom login web part
  • show: 884 sitelogin using FBA (, fake:bob1)show whitelistappshow custloginopenid.aspx
  • show MyOpenIDWhiteListMP: validateuser
  • SharePoint 2010 Custom Authentication Providers

    1. 1. SharePoint 2010Custom Authentication ProvidersBenjamin Steinhauser1/7/2012SharePoint Saturday Virginia Beach
    2. 2. About Me!• Name: Benjamin J. Steinhauser• Position: SharePoint Solutions Developer• Company: B&R Business Solutions• BSCS, MSCS; MCP, MCTS• 10+ years as ASP.NET Application Developer (C# and VB.NET) (yes, I admin it)• Built many (!!!) applications, specialized in Emergency Management and Notification systems• Lightweight SharePoint Developer since 2001 • versions: SharePoint Portal Server 2001, Microsoft SharePoint 2003, Microsoft Office SharePoint Server 2007, Microsoft SharePoint Server 2010• Went full-dev in SharePoint in 2010, loving it!
    3. 3. Topics• Introduction to and using SharePoint 2010 Claims Based Authentication• Typical web application authentication scenarios• Typical web application login scenarios• Building custom authentication providers (membership and role providers)• Extending SharePoint Web Applications to multiple zones, each with its own provider• Building custom Login pages and Login web parts• Introduction to OpenID: 3rd Party Identity Management, or Identities in the “CLOUD”• Examples!
    4. 4. SP Authentication Methods• Classic Mode Authentication • traditional Windows Authentication, same as WSS 3.0, MOSS 2007 • Windows Integrated (NTLM/Kerberos) • Basic (password in clear text! use SSL) • Anonymous • (-) No more FBA available when using Classic! • (+) Less confusing for simple Farms• Claims Based Authentication • new for SP2010 • built on Windows Identity Foundation (WIF) • everything is tokens, claims, identity provider, security token service • (+) All auth types are available • (-) woah, confusing
    5. 5. Claims Based Authentication• Supported Authentication Methods: • Windows: • NTLM (Windows) • Kerberos • Anonymous • Basic • Digest • FBA: • LDAP • MS SQL Server or other • custom or 3rd party membership and role providers • SAML token-based auth. • Active Directory Federation Services (AD FS) 2.0 • 3rd party identity provider • LDAP
    6. 6. Claims Based Authentication• SharePoint Server 2010 automatically changes all user 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• The claims token contains the claims pertaining to the user • Windows accounts are converted into Windows claims. • Forms-based membership users are transformed into forms-based authentication claims• Identity is stored in a security Token, contains one or more claims about the user • Claims are meta-data for the user• Access to SharePoint Server running in Claims Mode Authentication utilizes a Security Token Service (STS) which is essentially an authentication gateway to SharePoint Server that enables access for Windows Integrated Authentication, Form Based Authentication and Trusted Claims Providers (TRUST).
    7. 7. Claims Based Authentication• Windows Claims • In the Windows claims mode sign in, SharePoint Server authenticates the client using standard Integrated Windows authentication (NTLM/Kerberos) and then translate the resulting Windows Identity into a claims identity.• Forms-Based Authentication Claims • In forms-based authentication claims mode, SharePoint Server redirects the client to a login page hosting the standard ASP.NET login controls. The page authenticates the client using the ASP.NET membership provider, similar to the way in which forms-based authentication functions in Office SharePoint Server 2007. After the identity object that represents the user is created, SharePoint Server will then translate this identity to a claims identity object.• SAML-Claims • In SAML claims mode, SharePoint Server accepts SAML tokens from a trusted external Security Token Provider (STS) often known as a claims provider trust. A user who attempts to login is directed to an external claims provider (for example, Windows Live ID claims provider) which authenticates the user and produce a SAML token. SharePoint Server accepts and processes this token, augmenting the claims and creating a claims identity object for the user.
    8. 8. What!?
    9. 9. Claims Allows Mixed Mode• A single Web Application that uses Claims Based Authentication can support multiple modes of authentication simultaneously (not extended, only using Default Zone)• Mixed Mode authentication: • 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***
    10. 10. Mixed Mode Pros/Cons• CONS: • (-) No more transparent Auth. in an Intranet Environment • sign in required, custom solution available here: • SharePoint 2010: transparent login with mixed authentication • (-) 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 users• PROS: • (+) Only one web.config file to make changes in • (+) 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
    11. 11. FBA in SP2010
    12. 12. FOCUS: FBA in SP2010• Must use Claims Based Authentication to use FBA• STS manages Claims, Tokens, etc.• Components to build: • Membership Provider • Role Provider • Custom Login Pages • Custom Login Web Part
    13. 13. SP 2010 FBA Basics• First Web Application created should always handle Windows Authentication (can add FBA for mixed mode if necessary) • Default Zone: support Windows Auth (integrated or basic) • for search crawl, strong authentication, easier administration (Office 2010, SPDesigner, Remote Access)• If not using mixed mode, and dedicated FBA site wanted (typical scenario), extend the Web Application, choose new zone (internet, extranet, custom)
    14. 14. CODE: Membership Provider• Specify ASP.NET Membership provider name (REQUIRED) • 2 built-in OOB Providers: • LDAP/AD: ActiveDirectoryMembershipProvider • MSSQL: System.Web.Security.SqlMembershipProvider (extensive documentation for this available on internet) • Custom: • any custom .NET class inheriting MembershipProvider base class • must override certain function 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, Sqlite, etc.) • add .NET class to GAC or local web application BIN folder • Can be deployed as a solution (WSP) easily to either GAC or BIN
    15. 15. CODE: Role Provider• Specify ASP.NET Role manager name (OPTIONAL): • 1 Built-in OOB Provider: • MSSQL: System.Web.Security.SqlRoleProvider • LDAP/AD Role Provider available at • Custom: • similar to Membership provider: • any custom .NET class inheriting RoleProvider base class • must override certain function for SharePoint: • GetUsersInRole, IsUserInRole, GetAllRoles, FindUsersInRole, GetRolesForUser, RoleExists • can connect to any identity repository available that .NET code can access (ex. Oracle, Facebook, Twitter, SQL Server, XML File, Sqlite, etc.) • 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)
    16. 16. XML: Web.config changes• 3 web.config files (at a minimum) to be changed: • Central Administration (CA) • Security Token Service (STS) • Web Application (WA) that will be used to authenticate FBA users • may have more than one WA requiring changes, depending on configuration
    17. 17. XML: Central Admin Changes• CA Changes: • Location: C:inetpubwwwrootwssvirtualdirectories### • PeoplePickerWildcard (Optional): • add key = “Membership Provider Name” • add value = a wild card, ex. “%” for SQL, “*” for AD/LDAP • Optional because depends on implementation of Membership Provider search function implementation • ConnectionStrings (Optional): • add connectionstring here if membership or role providers require database connectivity • Optional because depends on implementation of Membership and Role Provider functions • Appsettings (Optional): • add any custom application settings that are required by the Membership and Role Provider.
    18. 18. XML: CA Changes (cont.) • membership, role: • requires strong name of assembly if installed in GAC (typical) • can use gacutil.exe (part of .NET SDK), or GacView.exe (available here: • Central Administration by default uses Classic Mode Authentication, so Claims providers are missing • Only need to add the custom Providers (Membership and Role) as shown below, very reminiscent of WSS 3.0 and MOSS 2007.
    19. 19. XML: STS Changes• Location: • C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14WebServicesSecurityTokenweb.config• STS uses Claims Based Authentication, so default Membership and Role Provider are built-in Claims.• Add custom Membership and Role provider within sections (this whole section is usually missing in web.config, need to add)• Now STS can authenticate FBA users, and convert FBA identities to Claims identities.• Add ConnectionStrings, AppSettings if needed (PeoplePickerWildcard not needed).
    20. 20. XML: WA Changes• PeoplePickerWildcards• ConnectionStrings• AppSettings• Membership and Role Provider: • FBA Web Application is Claims Based, so default providers are built-in Claims • Same changes as STS
    21. 21. Adding User Policy• CA web.config was updated so FBA users can be added as: • site collection administrator • “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• Adding Policy: • Open Web Application Settings in CA • Select the Web Application, click “User Policy” button in Ribbon • Click “add users” in modal/dialog window • Choose either All Zones or the Zone the FBA web application uses • Find the user using the people picker, check “Full Control”, and save
    22. 22. Application Pool Identity Permissions• Database and other Resource Permissions: • SQL Server: • Not to worry if connection string to database that Providers use is SQL Account (not Windows Account) (mixed mode auth in DB enabled). • However, if integrated mode is used, then the web application identity must have access to the database, and anonymous access in IIS can complicate this • Other repositories: • Same issue, identity of application pool needs access to the resources
    23. 23. Typical Login Scenarios• Windows Authentication: • Windows Popup (with or without domain name)• FBA: • OOB Login Page (built-in, can update, override, or replace) • Custom Login Page (regular ASP.NET Page, fully customizable) • anonymous access not required if login page does not use SharePoint 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 • PROS: • 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: OpenID) • Site Agreements, Information Policies: agreements, privacy, EULA, etc. • Multi-Factor authentication: using SMS, tokens, etc.
    24. 24. Custom Login Page/Web Part• SharePoint 2007 (and older): • uses System.Web.Security.FormsAuthenication class to handle building ticket and redirecting.• SharePoint 2010: • uses Microsoft.SharePoint.IdentityModel class to handle Claims authentication • DLL is already loaded in GAC in Foundation 2010, need path to DLL (in assembly) to add to Visual Studio as a Reference • Use Gacview.exe (previously mentioned) to get path to DLL• Login page can be either: • Custom Application Page (Visual Studio 2010 SharePoint Project: Application Page) • Custom Web Part (Visual Studio 2010 SharePoint Project: Web Part or Visual Web Part) (added to web part page in SharePoint)• Login page “asks” STS to authenticate user using IdentityModel.SPClaimsUtility.AuthenticateFormsUser function.
    25. 25. Custom Login Page/Web Part• Specify login page for web application by: • Open CA, Application Management, Manage Web Apps • Select the web application • Click “Authentication Providers” in the ribbon • Select the Zone that uses FBA • In the section named “Sign In Page URL”, choose “Custom Sign In Page” • Enter the URL of the custom page: • ex: /_layouts/fbaaddons/custloginoob.aspx • can also be a web part page in a SharePoint site, but site would need anonymous access turned on
    26. 26. Putting it together• Visual Studio 2010: • Empty SharePoint 2010 Project – FBAAddOns • Class: Providers.cs • Web Parts: • Login Web Part • Application Pages: • Login Web Page • OpenID Web Page • Reference: DotNetOpenAuth.dll• Demo: • Creating the above…
    27. 27. OpenIDSharePoint 2010 and OpenID
    28. 28. Identities in the Cloud!• 3rd party Identity Management• Decentralized Authentication• Internet Drivers License• Common Internet Implementations: • Facebook, Google, OpenID, Twitter• Academic: • Yale CAS (central authentication service) • Shibboleth• Identity is known (username, email, etc.)• Password is not
    29. 29. OpenID Explained• One billion OpenID enabled user accounts and over 50,000 websites accepting OpenID for logins.• Several large organizations either issue or accept OpenIDs, including Google, Facebook, Yahoo!, Microsoft, AOL, MySpace, Sears, Universal Music Group, France Telecom, Novell, Sun, Telecom Italia, and many more.• Concepts: • Identity Provider (server, service provider): • owns the identity • confirms the identity with participating web sites (assertions) • maintain multiple “profiles” under one identity • Relying Party (client, consumer) • requests identity from Identity Provider • uses identity • maps identity to internal identity (whitelist of users) • OpenID Identifier: is the url or xri chosen by the end-user to name the end-users identity (ex:• Resources: • •
    30. 30. OpenID Pros/Cons• PROS: • 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 with websites that accept OpenIDs) • Minimize Password Security Risks • Yo! 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?!? • code, code, code (scares management :P)
    31. 31. Enough BS, Lets see some examples!
    32. 32. Welcome to• Web Application and Zones: • Default: 881: Mixed Mode Claims Based Authentication: • Windows Authentication & FBA Authentication (custom membership and role providers) • No anonymous access • Dynamic roles • Internet: 882: FBA Claims Based Authentication: • FBA Only (custom membership and role providers) • Uses custom login page • No anonymous access • Dynamic roles • Custom: 883: FBA Claims Based Authentication: • FBA Only (custom membership and role providers) • Uses custom login page: web part page, uses custom login web part • Anonymous access enabled • Dynamic roles • Extranet: 884: FBA Claims Based Authentication: • FBA Only (custom membership and role providers) • Uses custom OpenID Provider, custom login page, can authenticate to local Identity Provider and • No anonymous access
    33. 33. 1. Mixed Mode Claims Based Auth• Default Zone, port 881• Uses Windows Authentication• Uses FBA, providers: • Membership: CustomDbUsersMP “Nice…” • custom SQL Server table: CustomDbUsersLists • custom Dynamic data application to manage users (L2S) • users: user1, user2, user3 • Role: CustomDbUsersRP • custom C# code: 1 role, name = “DynamicAdmins” • Table “CustomDbUsersLists” has a column “isadmin” (int) • if user record “isadmin”=1, then IS member of role• No anonymous access• No custom login page
    34. 34. 2. FBA Claims Based Auth• Internet Zone, port 882• Uses FBA only, providers: • Membership: CustomDbUsersMP • Role: CustomDbUsersRP• No anonymous access “Cool!”• Custom login page • url: /_layouts/fbaaddons/custloginoob.aspx • includes a mandatory “policy agreement” before logging in
    35. 35. 3. FBA Claims Based Auth• Custom Zone, port 883• Uses FBA only, providers: • Membership: CustomDbUsersMP • Role: CustomDbUsersRP• Anonymous access enabled “Wow!” • (in CA WA settings, and WA site settings)• Custom login page • url: /Custom%20Pages/CustomLogin.aspx • Custom login web part • added to a standard SharePoint web part page • includes a mandatory “policy agreement” before logging in
    36. 36. 4. FBA Claims Based Auth• Extranet Zone, port 884• Uses FBA only, providers: • Membership: MyOpenIDWhiteListMP • custom SQL Server table: MyOpenIDWhiteList • custom Dynamic data application to manage users (L2S) • table acts as whitelist/mapping (needed for membership provider to resolve user to add to SharePoint) • users: • fake: bob1, bob2, bob3 “OMG!” • real: bandrben • Role: [none]• No anonymous access• Custom login page • url: /_layouts/fbaaddons/CustLoginOpenID.aspx • uses DotNetOpenAuth.dll (added to BIN not GAC) • requires elevated trust in WA web.config (FULL) • enter OpenID url • use either: (local) • or, (real)
    37. 37. ValidateUser for OpenID• How to implement the ValidateUser(username, password) function in the MembershipProvider class? • used to authenticate the user • both fields required to override ValidateUser in base class • OPTION 1: blank password/skip password evaluation: • poor security: can a user login using another web application’s login page? what about web services, REST, Client OM, etc? • OPTION 2: username + salt + AES/3DES/SHA/MD5 • Custom Login page calls: • SPClaimsUtility.AuthenticateFormsUser(Request.Url, username, password) • STS calls Membership.ValidateUser(username, password) • password transmitted should be: aesEncrypt(username + salt) • Membership.ValidateUser(u, p) implementation: • recreate password sent to function, by applying same algorithm • compare passwords, should be same
    38. 38. Future Considerations• User Profiles: • Either, custom sync timer job or integration with User Profile Sync Service Application • or, handle on login, when resolving with WhiteList/Mapping• WhileList/Mapping application: for managing identities of users coming from 3rd party providers (Cloud)• Client application integration (MS Office 2010)• Configuring Search, Alternate Access Mappings
    39. 39. Questions? Thanks!• For Source Code & Presentation:• For Clippy:• Presentation: providers• For more information: • @njitben • •• References • MOSS 2007 • • FBA-Walkthrough-Part-1.aspx • • SP 2010: • • • • authentication.aspx • • • OpenID • •
    40. 40. Our Sponsors