SharePoint 2013 integration with Siteminder issue

[Anon Anon]

I've been trying to get SharePoint 2013 and Siteminder 12.52 Sp1 to play nicely together with no success. Despite trying a number of things no matter what identity claim I try and use with SP when I try and authenticate I can see the back and forth between Siteminder and SP and the STS call to issue the new security token but in the ULS viewer but am getting the following error:

 

"Trusted login provider SAML for SP is not sending the configured input identity claim http://schemas.xmlsoap.org/claims/upn"

 

In the siteminder console under the Assertion attributes and namespace sections it clearly specifies the same URL as shown above in the error message.

 

Any ideas what I'm missing?

 

Thanks in advance for any ideas!

[Legacy User]

Hello ,

 

Are you referring to the correct attribute name for the authorization at sharepoint end ? you need to refer to the same attribute that is sent by siteminder/IDP . For ex:- IDP is sending attribute name "ABC" then you can do something like "New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/ERIWAMUSER" -IncomingClaimTypeDisplayName "ABC" –SameAsIncoming" in your application.

You can try this and see how it works !

Thanks

[Chris Bertagnolli]

The command that was run on Sharepoint side was:

 

 

$upnMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/upn" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming

 

$emailMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/emailaddress" -IncomingClaimTypeDisplayName "Email Address" –SameAsIncoming

 

 

Then in SiteMinder WS-Fed partnership, setup the assertion for:

 

http://schemas.xmlsoap.org/claims/emailaddress

http://schemas.xmlsoap.org/claims/

User Attribute

Email

http://schemas.xmlsoap.org/claims/upn

http://schemas.xmlsoap.org/claims/

User Attribute

userPrincipalName

Looking at the trace, we'll see the WS-Fed/SAML 1.1 token going across with the email address and UPN attributes. However, Sharepoint still throws up saying it's not there.

 

Unfortunately all the documentation at CA is for the Sharepoint Agent but we don't need the proxy agent...only need centralized IdP (WA 12.52 w/ WOAP) that uses SM to do the authentication straight up WS-Fed/SAML1.1 if that's possible.

[Anon Anon]

we are encountering the same problem . did this got resolved?

is there any CA suggestion on what could be done in this case.

 

Our requirement: is also in the similar lines where we dont want to use sharepoint agent , we are trying to acheive the authentication using the ws-fed token with sharepoint 2013.

[Sandeep Kumar Noolu]

Hi, can you please advise how you fixed this issue ?  Thanks.

[Chris Bertagnolli]

Fixed our issue by not using CA product to integrate it. Never could get it working to SiteMinder OOB and CA just wants folks to buy their custom agent.

 

We used ADFS and setup SiteMinder as a Claims Provider Trust.  So Sharepoint -- WS-Fed --> ADFS -- SAML 2.0 --> SiteMinder.

 

This way we could continue using our normal custom log in forms and the authentication services that rely on SiteMinder. But get the benefit from the app viewpoint of it just being a standard ADFS WS-Fed integration.

 

No point spending tons of $$$ on the SharePoint agent when ADFS is basically free in terms of license . And it can do a lot of stuff that SiteMinder can't - like has a WS-Trust endpoint for exchanging cert auth for a signed JWT, better claims manipulation, etc.

 

It's been a pretty useful tool to add into our overall collection of capabilities. Especially when working with other Microsoft products. With the two products we've been able to cover much more than either one by itself could do.

 

---

 

Some considerations with that setup:

 

- By default, you'll get the IDP Discovery page of ADFS. If you want to avoid this so a user is just immediately sent to your SiteMinder IDP run a PowerShell command like this:

 

Set-AdfsRelyingPartyTrust -TargetName "MyRelyingParty" -ClaimsProviderName @("SiteMinderIDP")

 

- ADFS supports wildcard for return URL. For all the dynamically generated sites you'll want to leverage this. So trusted URL on relying party would have something like "https://*.mysharepoint.domain.com".

 

This way it will accept any of the site generate URLs within that domain.

 

- User-friendly two-factor enforcement can be tricky. Just be sure to test it in your environment and adjust accordingly. E.g., I authorize in ADFS on "authlevel" returned from SiteMinder. If this fails, default I just get an ugly error at ADFS with no useful information.

 

- One other thing if you consider using the Web Application Proxy (WAP), I believe it can support front-ending SharePoint without requiring it going WS-Fed. I've not done it but talked with others who have similar setup. WAP is a reverse proxy solution that goes with ADFS and can front-end "non-claims aware" applications. My understanding is that can front-end SharePoint, you authenticate to WAP which goes and does Kerberos to back-end...so SharePoint itself doesn't have to switch to be WS-Fed/SAML.

 

Again, haven't personally set this up. But might be worth investigating if you consider ADFS route.