My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, December 12, 2010
« Want ABAC? Across Organizations? Start w... | Main | Identity Oracles and their role in the I... »

I am doing a bit of research into what it would take to deploy Sharepoint 2010 as a DMZ facing portal that accepts Federated Credentials.  Here are some materials I’ve come across that may help others who may be doing the same:

From MS PDC10 Presentation “How Microsoft Sharepoint 2010 was built with Windows Identity Foundation”:

Classic Authentication

Claims-based Authentication

  • NT Token Windows Identity
  • NT Token Windows Identity
  • ASP.NET Forms Based Authentication (SQL, LDAP, Custom …)
  • SAML 1.1++
  >>> SAML Token Claims Based Identity
>>> SPUser >>> SPUser

More details regarding the above can be found at the MS Technet page on Authentication methods supported in SP2010 Foundation.

Windows Identity Foundation (WIF) which is the RP piece integrated with Sharepoint 2010 (SP2010) does NOT support the SAML Protocol. It only supports the WS-Federation Passive profile with SAML tokens for Web SSO.

Alternative to get SP2010 to work with a SAML2 IdP requires the deployment and usage of ADFS 2:

  • Configure ADFS 2 as a SAML2 SP that accepts attributes/claims from an external SAML2 IdP
    • Define the SAML2 IdP as a SAML2 Claims Provider within ADFS 2
    • Exchange federation metadata between SAML2 IdP and ADFS 2 SP
  • Configure the WIF based application (i.e. SP2010 application) as a RP which points to ADFS 2.0 as the Sharepoint-STS (SP-STS) to which the web apps externalize Authentication

Of course, this implies that you need to deploy another server in the DMZ that is hosting the ADFS 2 bits.

In order to configure SP2010 Authentication to work with SAML Tokens:

  1. Export the token-signing certificate from the IP-STS. This certificate is known as the ImportTrustCertificate. Copy the certificate to a server computer in the SharePoint Server 2010 farm.
  2. Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. Many examples of this process use the user e-mail name as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows which value in the token will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. Claims mappings are created by using Windows PowerShell.
  3. Define additional claims mappings. Define which additional claims from the incoming token will be used by the SharePoint Server 2010 farm. User roles are an example of a claim that can be used to permission resources in the SharePoint Server 2010 farm. All claims from an incoming token that do not have a mapping will be discarded.
  4. Create a new authentication provider by using Windows PowerShell to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint Web applications that you are configuring for SAML token-based authentication. After the SPTrustedIdentityTokenIssuer is created, you can create and add more realms for additional SharePoint Web applications. This is how you configure multiple Web applications to use the same SPTrustedIdentityTokenIssuer.
  5. For each realm that is added to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. This can be done before the SharePoint Web application is created. Regardless, you must plan the URL before you create the Web applications.
  6. Create a new SharePoint Web application and configure it to use the newly created authentication provider. The authentication provider will appear as an option in Central Administration when claims mode is selected for the Web application.

You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All providers that are configured will appear as options in Central Administration. Claims from different trusted STS environments will not conflict.

The SP2010 Authentication Flow then becomes:

  1. User attempts to access Sharepoint web application
  2. User redirected to Sharepoint STS
    - Validate AuthN Token (if user already has been AuthN w/ IdP)
    - Augment claims, if need be
  3. Post Token {SP-Token} to Sharepoint Web Application
  4. Extract Claims and construct IClaimsPrincipal

I still have a list of outstanding questions I am working thru, some of which are:

  • Can the built-in SP-STS do direct Authentication of X.509 Credentials for SP2010?
    • What "front-end" protocols are supported by this SP-STS? (WS-Fed Passive Profile only?)
    • Is there any MS "magic sauce" added to this SP-STS that "extends" the standards to make it work with SP2010?
    • Can the built-in SP-STS do direct Authentication of X.509 credentials?
    • Can the built-in the SP-STS do just in time provisioning of users to SP2010? Is it needed?
  • When using ADFS 2 with SP2010, does ADFS 2 replace the built-in SP-STS or does it work in conjunction with the SP-STS? i.e. if using ADFS 2, can the built-in SP-STS be disabled?
    • Can ADFS 2 do direct Authentication of X.509 credentials?
    • Can ADFS 2 do just in time provisioning of users to SP2010? Is it needed?
  • Does this SP-STS need to be ADFS 2.0 or can it be any STS that can do SAML2 to WS-Fed token transformation on the RP side?
  • If it can be any STS, how do I register a non-Microsoft STS w/ SP2010? i.e. How do I register it as a "SPTrustedIdentityTokenIssuer"
  • Where can I find the metadata on the SP2010 side that can be exported to bootstrap the registration of a SP2010 RP App with an external IdP?

Part of the issue I am working thru is the differences in terminology between Microsoft and …everyone else… :-) that is used to describe the same identity infrastructure components. Walking thru some of the ADFS 2.0 Step-by-Step and How To Guides, especially the ones that show interop configurations with Ping Identity Pingfederate and Shibboleth 2, do help but not as much as I had hoped.  The primary limitation of the guides is that they do the wizard driven click-thru UI configuration without explaining why things are being done or providing explanations on the underlying protocols that are supported and the implementation choices that are made.

Tags:: Architecture | Security
12/12/2010 3:57 PM Eastern Standard Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.