SharePoint 2010 Custom Authentication Providers

SharePoint 2010
Custom Authentication Providers
Benjamin Steinhauser
1/7/2012
SharePoint Saturday Virginia Beach

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!

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!

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

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

• 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).

• 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.

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***

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
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
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

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

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)

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

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 codeproject.com
• 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)

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

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.

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:
http://www.nirsoft.net/dot_net_tools/gac_viewer.html)
• 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.

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).

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

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

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

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.

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.

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

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…

OpenID
SharePoint 2010 and OpenID

Identities in the Cloud!
• 3rd party Identity Management
• Decentralized Authentication
• Internet Drivers License
http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html

• Common Internet Implementations:
• Facebook, Google, OpenID, Twitter
• Academic:
• Yale CAS (central authentication service)
• Shibboleth
• Identity is known (username, email, etc.)
• Password is not

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-user's
identity (ex: http://bandrben.myopenid.com)
• Resources:
• http://openid.net
• http://www.dotnetopenauth.net/

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)

Enough BS, Lets see some examples!

Welcome to SPDevMutts.com
• 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
• Dynamic roles
• Custom: 883: FBA Claims Based Authentication:
• Uses custom login page: web part page, uses custom login web part
• Anonymous access enabled
• Dynamic roles
• Extranet: 884: FBA Claims Based Authentication:
• Uses custom OpenID Provider, custom login page, can authenticate to local Identity
Provider and http://www.myopenid.com

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 custom login page

2. FBA Claims Based Auth
• Internet Zone, port 882
• Uses FBA only, providers:
• Membership: CustomDbUsersMP
• No anonymous access “Cool!”

• Custom login page
• url: /_layouts/fbaaddons/custloginoob.aspx
• includes a mandatory “policy agreement” before logging in

• Custom Zone, port 883
• Membership: CustomDbUsersMP
• Anonymous access enabled “Wow!”

• (in CA WA settings, and WA site settings)
• 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

• Extranet Zone, port 884
• 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]
• 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: http://www.myopenid2.com/user.aspx/bob1 (local)
• or, http://bandrben.myopenid.com (real)

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

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

Questions? Thanks!
• For Source Code & Presentation: http://sp2010claimsfbaexs.codeplex.com/
• For Clippy: http://spclippy.codeplex.com/
• Presentation: http://www.slideshare.net/njitben/sharepoint-2010-custom-authentication-
providers
• For more information:
• @njitben
• bsteinhauser@bandrsolutions.com
• http://www.bandrsolutions.com

• References
• MOSS 2007
• http://www.codeproject.com/KB/sharepoint/FBA.aspx
• http://www.devcow.com/blogs/jdattis/archive/2007/02/23/Office-SharePoint-Server-2007-Forms-Based-Authentication-
FBA-Walkthrough-Part-1.aspx
• http://msdn.microsoft.com/en-us/library/bb975135(v=office.12).aspx
• SP 2010:
• http://www.orbitone.com/en/blog/archive/2010/06/23/sharepoint-2010-mixed-authentication-automatic-login.aspx
• http://technet.microsoft.com/en-us/library/cc262350.aspx
• http://blogs.msdn.com/b/chunliu/archive/2010/08/21/creating-a-custom-login-page-for-fba-in-sharepoint-2010.aspx
• http://blogs.msdn.com/b/pranab/archive/2010/07/26/how-to-create-custom-login-form-for-sharepoint-2010-form-based-
authentication.aspx
• http://donalconlon.wordpress.com/2010/02/23/configuring-forms-base-authentication-for-sharepoint-2010-using-iis7/
• http://www.mssharepointtips.com/tip.asp?id=1093&page=3
• OpenID
• http://www.dotnetopenauth.net/
• http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html

SharePoint 2010 Custom Authentication Providers

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (10)

Dernier

Dernier (20)

SharePoint 2010 Custom Authentication Providers

Notes de l'éditeur