SharePoint 2010 Federated with SiteMinder STS
资讯类别:SharePoint开发发布日期:2017-09-15 00:00:00      浏览次数:587 次
北京博皓科技有限公司:提供全面的SharePoint开发资讯

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:

 

这里有很多博客在讨论如何设置sharepoint 2010 和 ADFS 2.0的集成。我这有一个机会接到一个sharepoint 2010 同 CA SiteMinder STS做集成的任务。这里有我的一些笔记:

 

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 http://schemas.xmlsoap.org/claims so our two claim are: http://schemas.xmlsoap.org/claims/CommonName and http://schemas.xmlsoap.org/claims/EmailAddress

 

1. 在 SiteMinder这边,CA的人配置了一个 Response Provider ,它传出两种声明:Email address 和 CommonName,看起来SiteMinder用的是常规的命名空间:http://schemas.xmlsoap.org/claims  于是我们配置http://schemas.xmlsoap.org/claims/CommonName 和 http://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.

 

2.在sharepoint这边,我们导入了SiteMinder的 token signing certificate ,然后在TrustedRootAuthority中添加了证书链。在输入了一系列powershell命令之后我们创建并设置了一个名为“SiteMinder STS”的受信任的身份验证提供程序。这里有一个好的链接  how to setup sharepoint 2010 with ADFS v2 ,可以参照里面的步骤来配置sharepoint这边。

 

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

我们在初步配置之后遇到了一个奇怪的现象:

  • 用户访问sharepoint站点
  • 用户被重定向到SiteMinder的登录页面
  • 用户在SiteMinder验证通过并给与FedAuth cookie 后被重定向回sharepoint
  • 用户又被重定向回了SiteMinder

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.

在花了一些时间分析之后,我的伙伴Tyler Durham 给了我正确的指引, 然后我们发现SiteMinder 的 Token 过期时间是2分钟,于是我们调整了SiteMinder token 的过期时间到1个小时,这个问题解决了

 

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.

 

3. 设置完毕之后,用户看起来并不像那么回事儿,在peoplepicker里你输什么它显示什么(貌似是WS-Federation工作原理决定的,并不检索用户,只是假定有)于是我们做了一个自定义的 Custom Claim provider 在FillSearch和FillResolve之前解析用户。这里有一个链接 如何创建和注册Custom Claim Provider.        这段不确保翻译正确。。。未完。。。。等我搞完这个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 http://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.

北京博皓科技有限公司:提供全面的SharePoint开发资讯
展开
  • 在线咨询

  • 北京博皓科技有限公司WEB客服
  • 电话咨询

  • 13693577495