Now I’m going to log on with the user “ADCORP\Claims.UserR1.C” which has been configured with the role “ROLE_adcorp.app.ADFSAppClaimsContributor” through the group membership of a group called “GRP_R1_ADCORP-ADFS-Claims-App-Contributors”. So ADFS extracts, the user’s group memberships and tranforms the group “GRP_R1_ADCORP-ADFS-Claims-App-Contributors” into a role “ROLE_adcorp.app.ADFSAppClaimsContributor” along the way. So, let’s have a look at this!

Figure 1: The User Leveraging Forms Based Authentication

–

Figure 2: The Claims Issued To The User And Processed By Sharepoint

–

With regards to sign-out from both Sharepoint and ADFS, you might want to have a look at the following

At this point everything is in place for at least the primary site collection administrator to be able to logon against the SP2010 claims based web application. This way I’m able to configure roles within the SP2010 claims based web application to use roles to assign permissions. This allows other (federated) users to access the SP2010 web application based upon their assigned role.

SP2010 knows of three permissions and for each permission I have configured a role. If you have the role, you also get the corresponding permission.

At this point, right after the creation of the RP trust, no issuance transform rules exist and also no delegation authorization rules exist. However, one claim rule exists in the issuance authorization rules and that is whatever you selected (“Permit All” or “Deny All”) previously during the creation of the RP trust.

Now we need to create a relying party trust for the SP2010 web application and configure that accordingly! You can do that through the GUI or through PowerShell. I’m going to create the RP trust through the GUI and the configure it (issuing transform rules and authorization transform rules) through PowerShell.

Start the ADFS v2.0 MMC and navigate to the “AD FS 2.0\Trust Relationships\Relying Party Trusts” node. Right-click it and select the “Add Relying Party Trust…” option.

Specify a display name (e.g. Claims Based Sharepoint App) and click on “Next >”

Figure 3: The Add Relying Party Trust Wizard – Specify A Display Name

–

For the SP2010 web application select the “AD FS 2.0 profile” and click on “Next >”

Figure 4: The Add Relying Party Trust Wizard – Choose Profile

–

The connection to the SP2010 is already secured by SSL and therefore the security token, which is transmitted over the same connection, will also be secured by that! So, it is not needed to additionally encryption the security token itself. I honestly do not know if SP2010 supports this or not. If SP2010 would support this and you would want to enable it, you would need to provide the public part of the token decryption from SP2010. When encrypted, SP2010 would use its private key to decrypt the encrypted security token. In addition, after creating this RP trust, we also need to force ADFS not to encrypt the security token when using this RP trust.

Select the option “Enable support for the WS-Federation Passive Protocol” and specify the exact same URL as when the web application was created in SP2010 and add the _trust part to it. So, in total the URL should something like “https://app-claims.adcorp.lab:446/_trust/” (without the quotes).

Figure 6: The Add Relying Party Trust Wizard – URL

–

By default ADFS uses the URL as the identifier. Whatever identifier is used is not important. The only important things to remember are that it must be unique and it must be exactly the same (case-sensitive!) as what has already been configured within the SP2010 web application. In this case that would be: urn:app:sharepointclaimsapp

By default you can only configure “Permit All” or “Deny All”. After the creation of the RP trust you can configure all kinds of complicated conditions if you want to!. For now select the option “Permit all users to access this relying party” and click on “Next >”.

This page lists through the different tabs the configured options. Review them all and after that click on “Next >”.

Figure 9: The Add Relying Party Trust Wizard – Summary

–

By default the option “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” is selected. At this time UNcheck it as we will further configure the RP trust through PowerShell.

Figure 10: The Add Relying Party Trust Wizard – Finishing

–

To get the full configuration of the just created RP trust “Claims Based Sharepoint App”, use the following powershell command

Get-ADFSRelyingPartyTrust "Claims Based Sharepoint App"

Figure 11: The Configuration Of The RP Trust “Claims Based Sharepoint App”

–

First, we are going to disable security token encryption on the RP trust “Claims Based Sharepoint App”.

By default ADFS has one claims provider trust defined and configured called “Active Directory”. That CP trust is also configured with a default list of claims rules (see picture below). For more information about this also see:

In the “Type the description” field enter (without the quotes) “Issued Claims List”

Select the LIBRARIES heading

Click OK

Figure 5: Adding The Issued Claims List Web Page To The Quick Launch

–

Click on “Home”

You should now see web page under the Libraries section.

Figure 6: Libraries Section With The Issued Claims List Web Page

–

Click on “Issued Claims List”

Figure 7: The Issued Claims Within Sharepoint 2010

–

Now you may think….”Why is SP2010 using claims while we are using a Windows based account/ID?” The reason for that is that SP2010 internally works with claims, no matter what! If you look at the OriginalIssuer column you will see for a lot of the claims “Windows” as that is where the information originated from!

–

We now need to reconfigure the web application to use the previuosly configured ADFS authentication provider.

To be able to log on to the Web Application now it is also important to temporarily change the site collection administration to a federated claims ID instead of the temporarily configured Windows AD account/ID.

So, if not already started, start the Sharepoint 2010 Central Administration Web Site and

The federation related part of sharepoint is done! Let’s now create the Web Application/Site. First I’m going to collect the credentials of the AD user account that will be used by the application as the applicationpool account , then I’m going to create a managed account in SP2010 based upon the previously mentioned AD user account, which by the way must be enabled, and finally I will specify the URL and port port for the Web Application/Site.

Figure 2: Creating The Web Application And The Site Collection Within Sharepoint 2010

–

Now let’s configure the correct SPN on the AD user account used within the Application Pool for the previously created Web Application.

Figure 3: Configuring The SPN On The AD User Account Used Within The Application Pool

–

Before starting to go crazy and throw claims against SP2010 we still need to configure other stuff. To see which claims SP2010 has accepted/used I want to deploy a webpart into SP2010 for my Claims Based Web Application. The webpart I’m using is based upon the following blog post: How To Create a Claims Viewer Web Part for SharePoint 2010.

However, at this point ADFS is still not configured, so I cannot authenticate against the SP 2010 Web Application using claims to deploy the webpart. Because of that I’m going to reconfigure the web application to temporarily accept Windows Based Authentication leveraging the Kerberos protocol.

Now I’m going to define the claims within SP2010 that the trusted ADFS STS is able to issue for SP2010. SP2010 will be made aware of these claims when creating the authentication provider within SP2010 later on. By the way, the claims shown as specific to my environment and most likely may not, or even are not, used within your own environment. Before continuing with the PowerShell code below, make sure to start the Sharepoint Management Shell first.

Figure 1: Defining All The Claims That Can Be Used Within Sharepoint 2010 When Send From The Trusted ADFS STS

–

Now I’m going to define the federation service identifier (realm) that defines the application within both SP 2010 and ADFS v2.0 and finally I will define the sign-in URL within ADFS v2.0. SP2010 will be made aware of these claims when creating the authentication provider within SP2010 later on. By the way, federation service identifier is case-sensitive, so do not shoot yourself in the foot by making it complicated. Choose either case and use that. If you need to specify the same name in multiple locations and you use different cases, then you will be troubleshooting after that, because it will not work. I have learned myself to use lower-case.

# Import The ADFS Snap-InAdd-PSSnapin Microsoft.Adfs.PowerShell
# Get The ADFS Service Name$adfsServiceName= (Get-ADFSProperties).HostName.ToLower()
$adfsServiceName# Get The Passive Federation Address Within ADFS$adfsFedPassiveAddress= (Get-ADFSProperties).FederationPassiveAddress
$adfsFedPassiveAddress# Define The Realm For Sharepoint That Identifies It Within Sharepoint And ADFS$realm="urn:app:sharepointclaimsapp"# Define The Signin URL$signInUrlADFS="https://"+$adfsServiceName+$adfsFedPassiveAddress$signInUrlADFS

–

The output of that all can be seen in the picture below.

Figure 2: Defining Federation Service ID For The Claims Based Web Application And The Sign-In URL Within ADFS

–

Now with all that information it is time to define the trusted authentication provider within SP2010.

I have been wanting to create this post for quite a long time. Reason for that is that when I started to learn about working with ADFS v2.0 I tried this by leveraging federated webSSO against a Sharepoint 2010 Web Application/Site. For me at that time, it was not easy and finding information on the internet on how to achieve this was also not easy. Lots of blog posts provided information, but were at some point lacking important steps or information. Because of that I want to post an end-to-end blog post and save somebody else from the exact same painful experience if you are trying to learn about ADFS v2.0 with for example Sharepoint 2010 as a Relying Party Claims Based Application. So here goes and have fun! Oh, by the way, I’m far from a Sharepoint 2010 specialist! So, if you have comments about that, feel free to use the comments section to say whatever you want to say. Oh, heck I don’t care. Whatever you want to comment on, go ahead and do so so that everybody is able to learn from it!

This explanation assumes everything is installed on one box! If stuff is separated on different boxes, then some of the scripts may need to be changed accordingly. With the information I’m already giving you, that’s therefore something for you to figure out!

So, stay tuned as I will post this in different parts for the next few days! Have fun!

–

One thing that really surprised me, and you will hit it like me if you do not know about it, is that Sharepoint 2010 (SP2010) does not leverage the certificate stores in Windows. For whatever reason it has its own “Trusted Root CA Store”. Because of that, when a user presents a security token from the ADFS STS and signing by its own token signing certificate, SP2010 will wine about not trusting the token signing certificate from ADFS, although the corresponding root CA certificate indeed is in the Trusted Root Certificate Authorities on the Windows Server. So, to make SP2010 stop wining about this, you must import the root CA certificate into SP2010 own trusted root CA store.

So, first I will export the trusted root CA from Trusted Root Certificate Authorities on the Windows Server and write that to a file. Then I will read the certificate file and import it into SP2010 and of course check the trusted root CA actually is there. By the way, do not forget to change the paths and the name of your trusted root CA!

You can use the following PowerShell commands, but first make sure to start the Sharepoint Management Shell:

Now I’m going to export the Token Signing Certificate used by ADFS v2.0 so that it is recognized by SP2010 as the Token Signing Certificate of the STS trusted by SP2010. SP2010 will be made aware of this certificate when creating the authentication provider within SP2010 later on.

Figure 2: Exporting The Token Signing Certificate Used By ADFS From The Personal Certificate Store Of The Computer

–

If you have paid close attention you have noticed that the token signing certificate is from an internal PKI environment and therefore not self-signing. BUT… what if the token signing certificate indeed is self-signed and you are leveraging ADFS automatic certificate rollover? In that case you will not be able to export the self-signed certificate as it is not stored in the personal store of the computer, but rather in the ADFS Configuration database. I have not found a way to export that certificate from the database, BUT… there is a way to export it though! As you may remember, all certificates used by ADFS are listed in the federation metadata of the federation service! Therefore if you target the federation service you can get the token signing certificate used by ADFS. This applies to whatever certificate type you used (external PKI, internal PKI, self-signed). Something to be aware is that you need to target the correct section in the federation metadata and the certificate information is stored in Base64 format. So you have to decode that to bytes and save to a file. See the PowerShell below to see how to do that!

# Load The ADFS Snap-in And Get The Current DirectoryAdd-PSSnapin Microsoft.Adfs.Powershell
$CurrentDir= (Get-Location).Path
# Get The ADFS Federation Metadata URL$ADFSFederationMetadataURL= (Get-ADFSEndpoint |?{$_.Protocol -eq"Federation Metadata"}).FullUrl.ToString()
# Get The ADFS Federation Service Name/FQDN$ADFSServiceName= (Get-ADFSProperties | Select HostName).HostName
# Define The File Name That Will Store The Federation Metadata$ADFSFederationMetadataXMLFile="$CurrentDir\$ADFSServiceName_FederationMetadata.xml"# Download The Federation Metadata From The Specified URL And Save In The Defined XML File$WebClient= New-Object System.Net.WebClient
$WebClient.DownloadFile($ADFSFederationMetadataURL, $ADFSFederationMetadataXMLFile)
# Get The Content From The XML File$ADFSFederationMetadataXMLFileContent= [xml](Get-Content -Path $ADFSFederationMetadataXMLFile)
# Get The Base64 Encoded Version Of The Token Signing Certificate$ADFSTokenSigningCertBase64= ($ADFSFederationMetadataXMLFileContent.EntityDescriptor.RoleDescriptor |?{$_.type -eq"fed:SecurityTokenServiceType"}).KeyDescriptor.KeyInfo.X509Data.X509Certificate
# Convert The Base64 Format Into Bytes Format$ADFSTokenSigningCertBytes= [System.Convert]::FromBase64String($ADFSTokenSigningCertBase64)
# Write The Bytes To A Certificate File[system.IO.file]::WriteAllBytes("$CurrentDir\$ADFSServiceName.STS.TOKEN.SIGNING.CER", $ADFSTokenSigningCertBytes)

–

The output of that all can be seen in the picture below.

Figure 3: Exporting The Token Signing Certificate Used By ADFS From The Federation Metadata