SharePoint 2010 Federated with SiteMinder STS

  • Article

There are lots of blogs that talks about how to setup SharePoint 2010 with ADFS v2. I had an opportunity to be tasked to configure SharePoint 2010 to trust CA Site Minder STS. Here are some of my notes:

1. At SiteMinder side, CA people configured a RP to send out two claims: email address and CommonName, it seems that the namespace from SiteMinder is defaulted to https://schemas.xmlsoap.org/claims so our two claim are: https://schemas.xmlsoap.org/claims/CommonName and https://schemas.xmlsoap.org/claims/EmailAddress

2. At SharePoint side, we imported the Site Minder token signing certificates and added the chain of certificates to TrustedRootAuthority then run series of other scripts to setup the Trusted Identity Provider named “SiteMinder STS”. Here is a good link on how to setup SharePoint 2010 with ADFS v2 and the steps are exactly the same on SharePoint side.

We encountered a strange behavior after initial configuration:

  • user access the SharePoint site
  • user is redirected to SiteMinder login page
  • user is redirected back to SharePoint after authenticated by SiteMinder with FedAuth cookie
  • user is redirected right back to SiteMinder again

Spent some fair amount of time on it and my co-worker Tyler Durham pointed me the right direction and we found out the the Token lifetime of SiteMinder is 2 minutes so we adjusted the SiteMinder’s token lifetime to 1 hour and the problem went away.

3. After this setup, user does not like that in peoplepicker, anything you typed in will be resolved so we went ahead to build a Custom Claim Provider for resolving the names by override the FillSearch and FillResolve. Here is the link how to build and register Custom Claim Provider.

4. Then user request to only allow normal user to search users that are already in the current site collection so we run the following command on the web application: stsadm –o setproperty –url https://mywebapplication –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes

after this, I found out that my FillSearch code is no longer works since SharePoint restrict the search only within the site collection.

5. Then user want to have site collection admins to be able to resolve names against LDAP store and normal user only allow to resolve names from within the current site collection so I modified the FillResolve code to check if current user is Site admin or not then search the user from different store.

6. Then user want to hide the SiteMinder STS hierarchy at left panel of peoplepicker search window so I run the following powershell command to make my custom claim provider the default claim provider of SiteMinder STS according to Steve’s blog:

$trusted = Get-SPTrustedIdentityTokenIssuer -Identity "SiteMinder STS"
$trusted.ClaimProviderName = “internal name of your custom claim provider”
$trusted.Update()

7.  Right after we made our custom claim provider the defaullt provider  of the SiteMinder STS we found out that the resolved claim is not the claim what SiteMinder STS sends in so we followed another Steve’s blog to made the following changes of the custom claim provider to get it work correctly:

  • Created a internal static string TrustedIdentityTokenIssuerName = “SiteMinder STS” – this must be the same name as the Trusted Identity Provider
  • Instead of using the CreateClaim helper method and use the New SPClaim constructor

Side Notes:

At this moment, user cannot participate workflow or subscribe the alert because the SPUser’s email address is empty. How do we populate the email for the user?

One way of doing this is to develop a custom control to first check if current user’s email address (SPContext.Current.Web.CurrentUser.Email) is empty, if it is then get the email claim and then update the SPUser object and register it as delegate control available in the master page.