Windows Authentication and Trusted Identity Provider - User mapping to a single identity store

Question

First, let me describe the scenario:

I have a Web Application with 2 enabled Identity Providers

• Windows Authentication
• Custom Trusted Identity Provider (that provider handles PingFederate SAML tokens)

All users that will access SharePoint are members of an Active Directory domain (the SharePoint farm is member of the same domain). Permissions to SharePoint content is granted based on Active Directory groups.

Now there are two ways how to "reach" the SharePoint.

• Way A: Some users log on to their PC (which means: they log on to the domain) and access SharePoint using Windows Authentication. No problem with that way.
• Way B: Some other users DO NOT log on to the domain using their PC. Instead they log on to a web portal which issues a PingFederate SAML token. This token is used to authenticate the user in SharePoint via the Trusted Identity Provider.

Now the challenge:

Since every user is member of the Active Directory domain, those users who are using way B should be treated as if they've had used way A; they should be mapped to their appropriate AD account using the login ID from the web portal (web portal ID and AD SamAccountName are equal). Means: the PingFederate SAML token (the SAML claim) should somehow be converted to a Windows Authentication token (Windows Claim), if that's possible. Those users (way B) should be displayed in SharePoint the same way as users of way A. Furthermore users of way B should be granted access to content via Active Directory groups.

Is this possible? Can someone please give some hints how to achieve that (Custom Claims Provider)? Do I need to augment claims (AD group membership) for those users coming over way B? Is there a way to convert SAML tokens from (in this case) PingFederate SAML token to Windows Authentication SAML token?

Answer 1

Bear with me as I'm more SharePoint admin than PING expert but I've had to work on a similar solution for our organisation (allbeit incomplete). For our SharePoint 2013 implimentation, we are aligning with the organisation's SSO using PING Federate. However, we typically control access to SharePoint site collections etc via AD groups. We were able to get the authentication side of things working with PING / SharePoint no worries, but controling with AD groups ... thats another story. In the end, we were able to hook into Active Directory (as a data store) from the PING side of things, and produce a "Role" type claim mapping to the "memberOf" attribute in AD. This in effect would pass all the AD groups that a person was a member of as a role claim to Sharepoint. The only issue being that it would pass each AD group as the FQDN. Not very pretty when resolving in the people picker. On the SharePoint side this would give multiple SAML claims for the Role, namely all the AD groups a person was a member of.

Type the full FQDN in the people picker and you can then control access to your Site etc via AD groups. We are still working on how to pass that claim as the CN of the AD group only, as to make for a nicer experience in the People Picker. We are also working on a Custom Claims Provider to provide resolution in the people picker.

This, in a sense, enabled us to remove the need for the AD authentication on the web application alltogether (remembering you will probably need to extend the web application and have AD authentication enabled so SharePoint crawls can still take place). In this way the user doesn't need to choose their authentication method (AD or PING).

Hope that all made sense and will assist someone out there with similar issues ...

Answer 2

An anonymous user posted the following (as an invalid edit) based on an article they found

https://www.pingidentity.com/support/solutions/index.cfm/How-to-process-a-LDAP-multi-valued-attribute-and-return-it-as-a-multi-valued-SAML-attribute673515

In PING, under the "Attribute Contract Fulfillment" step, we used an OGNL Expression similar to the following:

new org.sourceid.saml20.adapter.attribute.AttributeValue(#this.get("ds.YOUR AD.memberOf").toString().replaceAll("[|]","").replaceAll("CN=","").replaceAll(",OU=FileAccessGroups,OU=Resources,DC=ETC,DC=ETC,DC=ETC,DC=ETC,DC=ETC","").{?matches(".*")})

We changed the default Match to choose all strings rather than matching on CN=Admin as per the example given. This would iterate through all group strings and remove anything we specified with the .replaceAll(......). As you can see, you can add multiple .replaceAll /s to cater for the removal of any unwanted prefix / suffix / etc for the Group name. Ultimately this enabled us to isolate the AD group CN, without all the extra guff and pass them as separate role claims.

Within SharePoint, we used the LDAPCP Custom Claims provider Project from CodePlex to resolve AD groups names from AD (in the people picker). Ensure the role claim type is mapped to the LDAP attribute cn and LDAP object class is group.

Disclaimer: I have not checked the above.

Answer 3

I'm not aware of any product doing the required work. In a design phase one could choose a different approach to authentication from the outside (ADFS, TMG with OTP, ...) but it sound like you are stuck to the current implementation. I'm not sure if there is a transparent way but let me describe my ideas:

I would try to get rid of the SAML authentication part. On the SharePoint side you would have to setup Kerberos and configure the environment to handle a Kerberos topic called "protocol transition". This feature will allow a process to impersonate any user (some exceptions are in place) to specified Kerberos enabled resources like SharePoint. Microsoft’s TMG is doing some similar stuff: http://technet.microsoft.com/en-us/library/cc995228

I'm not aware if you could plug into TMG and customize the behavior to fit your needs, but I would not bet on it. We as a company did a setup of ISA 2006 using RSA OTP to authenticate users from the outside of the company (from the internet) without the need to enter their AD password. The authentication is done by RADIUS to validate the OTP and from here the ISA server is doing the protocol transition and impersonates the user to SharePoint.

In your scenario you could write a custom reverse proxy (using IIS, Application Request Routing and URL Rewrite engine all from MS) to take the SAML token from PING, validate the token and then the match it against AD. Impersonate the user using the protocol transition and from this point the PING identity will be the AD user to SharePoint. All AD stuff is working (Groups, ...).

We did a project just a few weeks ago where we developed a custom reverse proxy based on the mentioned tech from MS to pre validate SAML tokens before they hit the final AD integrated servers. This is not your scenario, but it show that you can intercept the traffic from the client and modify the stream to do some extra stuff.

Just to make my point clear: I would not recommend to do stuff like that in production, but if you can't change any parameters this could be starting point.