ADFS integration

[Johan Åkerstrøm]

Hello,

I sense a bit of open/propriety code politics here but hey it is not my prerogative criticize. But we are dealing with a well-defined and well abstracted authentication protocol in SAML. So if your front end authn solution is Shibboleth or ADFS now it doesn't mean it has to be at a later stage. 
I'm not a Shibboleth export by any stretch of imagination but want to contribute my two pennies worth. First a few questions, does Shibboleth support Kerberos? If yes, does Shibboleth support the AD-WIN2K-PAC Kerberos Authorization Data Type? If yes, anyone got a link to some docs/samples? Otherwise I guess it would be an external auth flow and configure tomcat for windows Kerberos, right? 

What I can say is that ADFS/WAP works very well as the front end authn mechanism if one wishes to achieve both SSO through Kerberos as well as forms based authn. 

The one main thing one needs to think about if you go down the Shibboleth only route for Office 365 integration is to get ImmutableID right. ImmutableID is the AD ObjectGUID base64 encoded. This does not have to be the actual AD ObjectGUID in Base64 format but it has to be the same ObjectGUID the users are created with in Azure AD. So if you are using Microsofts Azure AD sync tool or Microsoft Office 365 DirSync then it will be ObjectGUID but if you use other ways of creating the users then you have more freedom in what GUID this is. For example if you have an identity provisioning solution using FIM or if you use the PowerShell cmdlets then you can use whatever GUID as a source as you please. As long as the provisioned ImmutableID is the same as the SAML token ImmutableID then you will be fine. 

Check: https://msdn.microsoft.com/en-us/library/azure/jj205463.aspx

If you need to overcome the Claims Provider solution then you have two options in ADFSv3. 
1) Sets the preferred Claims Provider in the Relying Party trust (Set-AdfsRelyingPartyTrust -Name SOME_RP -ClaimsProviderName PREFERRED_CP)
2) This is the more complicated, neither super neat since it requires an additional request from the browser but more dynamic option. Deploy a new WebTheme (use the *-WebTheme and *-WebConfig powerShell cmdlets) with a the default javascript but add something like the following to the exported onload.js:

if(document.URL.indexOf("<SOME_TRIGGER FOR_WHATS_IN_WREPLY>") > -1  && !(document.URL.indexOf("whr=https%3A%2F%2Fidp.domain.com") > -1)) {
    window.location = document.URL + "&whr=https%3A%2F%2Fidp.feide.no"
}

This will cause the browser to add the home realm discovery parameter when you access a SP which contains <SOME_TRIGGER FOR_WHATS_IN_WREPLY> in the URL. 

Best regards
Johan Åkerstrøm
 
Solution architect, Skill AS
Tlf: +47 91850043 | E-post: ja at skill.no | Web: www.skill.no 
 
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Paul B. Henson
Sent: Wednesday, August 19, 2015 10:19 PM
To: Shib Users <users at shibboleth.net>
Subject: ADFS integration

So we are in the same boat as I assume many other people reliant on Microsoft services are, with both a shibboleth idp and an ADFS deployment. The powers that be are unhappy that they have to sign in separately to Office 365 etc, and want to integrate/consolidate authentication for all of our single sign-on applications.

In an ideal world, that would mean switching all of the proprietary Microsoft services to use our nice open standards-based and freely available shibboleth deployment. Unfortunately, although Microsoft has "improved" their ability to use a shibboleth idp to authenticate their online services, according to our Windows guys it is not officially "supported", and they refuse to do it.

That leaves us with somehow trying to integrate our shibboleth idp and our ADFS deployment. One of our application guys pointed out some work that Unicon has done in that department:

	https://github.com/Unicon/cas-adfs-integration/wiki

That's not going to work for a number of reasons; from a design perspective, there is absolutely no way I'm going to have all of our non-Microsoft services reliant on Microsoft proprietary ADFS, which is how the first option (delegating  CAS authentication to ADFS) works. The second option (delegating ADFS to CAS) would be more promising, except it requires clearpass to be enabled  on the CAS server, which I don't want to do. And finally, we are tentatively planning on migrating our CAS clients to idpv3 when we upgrade, and neither of those would work in that scenario anyway.

One of our Windows guys pointed out:

https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop

It sounds like this would allow an end-user to hit ADFS, then authenticate against a shibboleth idp, and continue on to access the ADFS authenticated application without explicitly authenticating to ADFS, which is exactly what I would want. However, it seems there is some extra interactivity in the process, where the user must select on the ADFS landing page that they want to authenticate to shibboleth instead of ADFS? And to avoid that, you would need to use an SSL offloading load balancer which injects cookies into the request? We don't currently do SSL offloading, and would prefer not to.

So, are there any other methods of achieving ADFS/shibboleth integration that we haven't happened upon? Is there any way when using the wiki method to make ADFS automatically delegate authentication to the shibboleth IDP without munging cookies in transit? Via preferably some local IIS configuration or whatnot?

Thanks much...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/ Operating Systems and Network Analyst  |  henson at cpp.edu California State Polytechnic University  |  Pomona CA 91768


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net