Supported Authentication Types & Methods In SharePoint 2013
SharePoint 2013 is able to support a variety of authentication methods and providers for the following types of authentications:
- Forms based authentication
- SAML token based authentication
- Windows authentication
One of the claims based identity management systems is forms based authentication (FBA). This is based on ASP.NET membership as well as role provider authentication. It can be used against credentials that are stored in an authentication provider including:
- AD DS
- Databases such as SQL
- Directory Services (NDS)
- Lightweight Directory Access Protocol (LDAP)
Forms based authentication validates the user based on various credentials that they type into a logon form such as a web page. Any requests that aren’t authenticated will be redirected to a logon page. The user must provide valid credentials and then submit them on the form. The system will then issue a cookie for any request to authenticate when there is a key for re-establishing the identity for any future requests. With forms based authentication, the user account credentials will always be sent as plain text. It is important that you don’t use forms based authentication without also using Secure Sockets Layer (SSL) for encryption purposes.
With SAML token based authentication in SharePoint 2013, the use of SAML 1.1 protocol is used as well as the WS Federation Passive Requestor Profile (WS-F PRP). This requires coordinating with administrators of a claims based environment. This can be your own internal environment or it can be a partnered environment. If you use AD FS 2.0, you have an SAML token based authentication environment in place.
With SAML token based authentication, there is an identity provider security token service in place (IP-STS). That is what issues SAML tokens for all users who have accounts included in the associated authentication provider. These tokens can have various numbers of claims per user. An example of an IP-STS is an AD FS 2.0 server.
With SharePoint 2013 the claims are included in tokens that the IP-STS issued in order to authorize a given user. With a claims environment, the application that accepts SAML tokens is also known as a relying party STS (RP-STS). A relying party application will receive the SAML token and use the claims inside to determine if it should grant a user access to the requested resource or not.
With SharePoint 2013, each of the web applications has been configured for use with a SAML provider and added to the IP-STS server as a separate RP-STS entry. This enables a SharePoint farm to represent many RP-STS entries within the IP-STS.
There is a set of authentication providers for SAML token based authentication. What they are though depends on the IP-STS in the claims environment. When using AD FS 2.0, authentication providers can include:
- AD DS in Windows Server 2008
- All editions of SQL Server 2005
- All editions of SQL Server 2008
- Windows Server 2003 Active Directory
Windows authentication relies on your existing Windows authentication provider (AD DS). It also uses the protocols that a Windows domain environment users to validate the credentials of connecting clients. The Windows authentication methods are used by both claims based and classing mode authentication. They include:
SharePoint 2013 isn’t a type of Windows authentication. However, it still supports anonymous authentication. Users are able to access SharePoint without the need to validate credentials. Anonymous authentication is going to default to be disabled.
With forms based authentication or SAML token based authentication, you can use LDAP environments. You want to use the authentication type that matches your current LDAP environment. If you don’t have such an environment, it is recommended that you use forms based authentication since it is simpler. If your authentication environment already supports WS Federation 1.1 and SAML 1.1 then it is recommended that you use SAML. SharePoint Sever 2013 has a built in LDAP provider, however it may be necessary for you to deploy a 3rd party LDAP provider.