May 07, 2013

ADFS/Shibboleth intergration (Office 365 and beyond)


With Office365 round the corner I thought I'd turn my attention to federated authentication as this appears to Microsoft's desired method of account authentication (suits me for security reasons). So here's the challenge, our web development team have a preferred single sign method using shibboleth, for simplicity Microsoft would suggest using ADFS. Well as I've found out it's possible to have the best of both worlds meaning the web development team can produce the rights look and feel from a single source, and we can integrate office365 using the simplicity of ADFS.

So how does this work, well I can't really comment on the shibboleth side of things as I'm not expert in this area, but I can comment on ADFS as it is pretty straightforward. Firstly configure the servers using Microsoft’s guidelines, once setup convert the 365 domain to federated using the appropriate PowerShell cmdlet ". Once tested and working with ADFS/ADFS proxy using forms authentication we can now move onto the shibboleth integration.

Configure a claim provider trust using the shibboleth server as the source.

Exchange metadata and make sure that home realm discovery picks up the new claim provider.

Next comes the clever bit, If you looked that the relying party trust configuration that office365 places onto your ADFS server, you will see that a custom claim rule has been written to take the windowsaccountname (DOMAIN\username) and then match this against the directories objectguid/immutable ID UPN to be passed in the token back to office365. We discovered an issue in that the claim back from shibboleth would contain only the username with no domain. To fix this you can add a custom claim provider rule that will convert the username (whatever term shibboleth would use) into domain\samaccountname expected by the office365 rule. I used the following custom claim provider rule :-

c:[Type == "urn:oid:0.9.2342.19200300.100.1.1"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = "DOMIAN\" + c.Value, ValueType = c.ValueType);

How can we make the process simpler for the user (ie no home realm discovery)

1. On the ADFS proxy Locate the HomeRealmDiscovery.aspx file and edit it so it contains the following:-

protected void Page_Init( object sender, EventArgs e )

{

PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;

PassiveIdentityProvidersDropDownList.DataBind();

PassiveIdentityProvidersDropDownList.Items.RemoveAt(0);

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

}

As you may have found out you cannot disable Active Directory as a claim provider. The above will configure the homerealm discovery to 1, Remove ‘Active Directory’ as an option and 2. Force the one and only option (shibboleth) to the user (ie no option just them pass along)

Last but not least you may run across a passive signout issue if the shibboleth provider does not support/allow passive signout which forces the ADFS server to present a generic error page. To get round this you can amend the error.aspx file on the ADFS proxy to have the following:-

else

{

ExceptionMessageLabel.Visible = System.Web.Configuration.WebConfigurationManager.AppSettings[ "displayExceptions" ] != null;

ExceptionMessageLabel.Text = Exception != null ? Exception.Message : String.Empty;

}

if (Exception.Message == "MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.")

{

Response.Redirect("http://url/uri_of_page_to_explain_signout");

}

This will forward the users to the above URL instead of presenting the error page.



August 2020

Mo Tu We Th Fr Sa Su
Jul |  Today  |
               1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31                  

Search this blog

Tags

Galleries

Blog archive

Loading…
RSS2.0 Atom
Not signed in
Sign in

Powered by BlogBuilder
© MMXX