SharePoint 2010 Claims and SAML

  • Security Token Service (STS): A specialized Web Services that issues security tokens.
    • RP-STS (Relying Party Security Token Service)
    • IP-STS (Identity Provider Security Token Service)
  • Relying Party: A ‘Consumer’ of Claims (i.e., SharePoint, ASP.NET, Web Site, etc.). Claims are provided through an STS (IP-STS only)
  • Windows Identity Foundation (WIF): A .NET library (set of APIs) that are used for consuming Identity Claims and building custom STSs, etc.
  • WIF is just a set of .NET classes. It is not an STS. We can go WIF -> IP-STS or WIF -> RP-STS -> IP-STS
  • SharePoint 2010/2013 STS: SharePoint Service Application developed using WIF that acts as RP-STS only. Acts as a pluggable aggregation point for a number of user configurable Trusted Identity Providers (IP-STSs). These could be hand built using WIF if required.
  • The SP STS is RP-STS i.e. it does not have a credential store to authenticate against. That’s why we have to federate it with ADFS which is IP-STS i.e. it authenticates against an AD in its domain.
  • ADFS 2.0: A Windows role designed specifically for federating an organization against an Active Directory instance only. Exposes an IP-STS endpoint built using WIF. It doesn’t allow to ‘aggregate’ other Identity Providers – it just allows to authenticate against a specific AD instance that may not be local therefore needs to be federated in order to support SSO.
  • AD authentication is already supported as an OOTB Trusted Identity Provider option by the SharePoint STS and if we wanted to use ADFS 2.0 instead we could just add this in as a Trusted Identity Provider (IP-STS)
  • We can configure the SharePoint STS to use ADFS 2.0 a Trusted Identity Provider (IP-STS), as well as, or instead of local AD.
  • ADFS can be either RP-STS or IP-STS. i.e., SP App. -> SP STS -> ADFS (RP) -> ADFS (IP) -> AD.
  • ADFS can be federated with many different IP-STS. The user can choose which one to use for authentication.
  • ADFS supports both SAML2 and WS-Fed as federation protocols. SP RP-STS only supports WS-Fed.
  • The only STS’s that incorporate WIF are ADFS and IdentityServer. Others are Java based.
  • When we federate ADFS, we provide the ability to authenticate against multiple credential stores. But if we choose to authenticate against an instance of ADFS, it uses the AD repository. When we install ADFS it finds the instance of AD in its domain. That’s the one it uses.
  • Windows Azure ACS 2.0: A service specifically for federating any configured third-party Identity Providers (i.e. Microsoft account, Google, Facebook and ADFS 2.0). Acts as a pluggable aggregation point for other Identity Providers for which it acts a bit like a Relying Party. Exposes an IP-STS endpoint built using WIF. The Identity Providers it aggregates are not necessarily IP-STSs but ACS 2.0 exposes everything through Claims using its built-in IP-STS.
  • We can configure the SharePoint STS to use Windows Azure ACS 2.0 a Trusted Identity Provider (IP-STS). This would make it very easy to support third-party authentication providers without developing our own IP-STS using WIF.
  • The IP-STS we federate with SP does not have to be ADFS – it can be anything that supports the WS-Federation protocol e.g. OpenAM, PingIdentity, Azure ACS. The main point is that at the end of the chain there has to be a credential store to authenticate against. This credential store does not have to be AD e.g. ADFS -> IdentityServer -> SQL Server.
  • ADFS and IWA: both authenticate against AD but only ADFS adds SSO and Federation functionality. Also ADFS provides all the claims-based plumbing – SAML token etc.
  • Never CHANGE the SharePoint RP-STS out for ADFS 2.0 running as an STS-RP. Never this: (Remove SP STS) SP app -> ADFS (RP-STS) -> Whatever Always something like this: SP app -> SP STS -> ADFS/ACS/OpenAM
  • ADFS 2.0 STS is built using WIF code. To perform the trust negotiation and claims exchange, RP-STS must talk to IP-STS.
  • Building a claims-based ASP.NET Web Application, i.e., Relying Party, using WIF, have develop/reuse and include an RP-STS into the App and configure this to have a trust relationship with an IP-STS. If not, we get Identity directly from an IP-STS using WIF.Like Azure ACS 2.0, ADFS 2.0 also used to federate against more IP-STSs.

Forms Based Authentication with custom Login page in SharePoint 2010

Step1: Create web app with Claims Based Authentication

  • From Central Administration
  • Application Management
  • Click Manage Web Applications
  • Select New
  • Now we are in “Create web application” page
  • Select Authentication mode to “Claims Based Authentication”
  • Give the name of Web app, Port number & Path
  • Chose Security configuration
  • From Claims Authentication Types, enable both WA and FBA
  • FBA section, give ASP.NET Membership provider name (“SQLMembershipProvider”)
  • Give Role Manager Name (“SQLRoleManager”)
  • Enter Sign in page URL [default], public URL and other information
  • click OK
  • Then, create a site collection
  • Go to Manage Web application
  • From the list of web applications chose “Authentication Providers”
  • From the dialog box you will see the Default zone
  • Set to the Claims authentication mode
  • Click the Default zone link where you can see the settings
  • Now the Application is ready
  • Browse the application, we can see the default screen 

Step2: Create ASPNETDB to configure membership and Role providers

  • Login to the server where SQL Server is installed
  • Open command prompt
  • navigate to location “%Sysroot%\Microsoft.NET\Framework\v2.0.50727”
  • Run the “aspnet_regsql.exe“ (ASP.NET SQL Server setup wizard)
  • Click “Next”
  • chose the option “Configure Sql server for application services”
  • Click “Next”
  • Give the SQL Server name and authentication information
  • by default it shows <default> means the name will be ASPNETDB, but you can change the name here if you want
  • Click “Next”
  • Finish the wizard 

Step3: Fill some data to this DB

  • Their is some tools available in Codeplex
  • Go to this site and download “Membershipseeder.zip
  • Extract it and run it
  • Create some of users and roles
  • Now, we are ready with DB with all some data 

Step3: Modify web.config of web application we created

Note: Before making any changes to the web.config file of any app, please take the backup

  • Add Connectionstring just above <System.Web> starts or just below </Sharepoint> ends

<connectionStrings>

<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />

</connectionStrings>

  • Add Providers for Membership and Role
  • Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
  • Make sure that you are not doing any changes to the existing providers.
  • By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
  • Finally the <rolemanager> section and <membership> section as shown below:
  • (new entries is in bold-italic):

<roleManager defaultProvider=”c” enabled=”true” cacheRolesInCookie=”false”>

<providers>

<add name=”c” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />

<add connectionStringName=”SQLConnectionString” applicationName=”/” description=”Stores and retrieves roles from SQL Server” name=”SQLRoleManager” type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</roleManager>

<membership defaultProvider=”i”>

<providers>

<add name=”i” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />

<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” description=”Stores and Retrieves membership data from SQL Server” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</membership>

  • Save all your changes

Step4: Modify web.config of of Central Administration site

Note: Before making any changes to the web.config file of any app, please take the backup

  • Add Connectionstring just above <System.Web> starts or just below </Sharepoint> ends

<connectionStrings>

<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog= ASPNETDB ” />

</connectionStrings>

  • Add Providers for Membership and Role
  • Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
  • Make sure that you are not doing any changes to the existing providers
  • By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
  • Finally the <rolemanager> section and <membership> section as shown below:
  • (new entries is in bold-italics):

<roleManager defaultProvider=”AspNetWindowsTokenRoleProvider” enabled=”true” cacheRolesInCookie=”false”>

<providers>

<add connectionStringName=”SQLConnectionString” applicationName=”/” description=”Stores and retrieves roles from SQL Server” name=”SQLRoleManager”type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</roleManager>

<membership defaultProvider=”SQLMembershipProvider”>

<providers>

<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” description=”Stores and Retrieves membership data from SQL Server” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</membership>

  • Save the web.config file 

Step5: Modify web.config of Security Token Service Application

  • Open IIS
  • From the list of sites available expand “SharePoint Web Services” and find SecurityTokenServiceApplication
  • Right click on the application and explore, which will opens the file system file location of the application. By default it will be in “%programfiles%\common files\Microsoft Shared\web server extensions\14\WebServices\SecurityToken”
  • Find the web.config of the application and modify it

Note: Before making any changes to the web.config file of any app, please take the backup

  • Just above <System.Web> starts, add the connection strings tag

<connectionStrings>

<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />

</connectionStrings>

  • Add Providers for Membership and Role
  • Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
  • Make sure that you are not doing any changes to the existing providers
  • By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
  • Finally the <rolemanager> section and <membership> section as shown below:
  • (new entries is in bold-italics):

<roleManager defaultProvider=”c” enabled=”true” cacheRolesInCookie=”false”>

<providers>

<add name=”c” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />

<add connectionStringName=”SQLConnectionString” applicationName=”/” description=”Stores and retrieves roles from SQL Server” name=”SQLRoleManager” type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</roleManager>

<membership defaultProvider=”i”>

<providers>

<add name=”i” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />

<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” description=”Stores and Retrieves membership data from SQL Server” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />

</providers>

</membership>

  • Save the web.config file

If everything is OK, then from central administration site and your FBA application, we can able to find the users from ASPNETDB (using people picker), and you can successfully logged-in to the site without any issue

Step6: Create custom Login Page

  • Start Visual Studio 2010
  • Create a new SharePoint 2010 project using the “Empty SharePoint Project” template.
  • Choose Farm Solution (We are going to deploy files to the SharePoint root, also known as the 14 hive, so we cannot use the sandbox here)
  • Add a new item to the project.  Choose to use the Application Page template and name the new page Login.aspx
  • Add a reference to the assembly “Microsoft.SharePoint.IdentityModel” ( It does not show up in the list of assemblies in the Add Reference dialog, you need to browse to it using the path “C:\Windows\assembly\GAC_MSIL\Microsoft.SharePoint.IdentityModel \14.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.IdentityModel.dll”
  • Add the code from the following site:
  •  http://tomaszrabinski.pl/wordpress/2011/06/23/sharepoint-2010-custom-login-page/
  • Publish
  • To configure your custom login page, Go to Central Administration
  • Click on “Manage web applications”
  • Click your web site,  This lights up the “Authentication Providers” ribbon button
  •  Click the Authentication Providers ribbon button
  • Choose the zone that you want to configure (this should be the zone that was extended for FBA, or the default zone).
  • Scroll down a bit and you’ll see where to configure the Sign In Page URL

Once that is done, our new sign-in page is now available and works as expected