How we do Office365 authentication

By |

I understand that our way of getting users signed into Office365 via Shibboleth is considered a little… scary. In the interest of transparency and community helpfulness, I hope this post will make it a little less scary 🙂

Overview

Office365 stores no passwords for users in the kent.ac.uk or kentforlife.net domains instead referring or proxying all Authentication requests back to us for processing. This is done in one of two ways:

  • Web: Standard SAML2 based redirect via HTTP-POST binding for local AuthN and subsequent assertion return via browser
  • Non-web: SAML2 extension ECP (Enhanced Client or Proxy) method which proxies the AuthN request back to us via SOAP and HTTP Basic Auth. This method is used for non-web processes such as ActiveSync or IMAP

Further complicating the setup is that Microsoft only support one EntityID to be associated with one Federation config at once. Therefore we need two instances of the Shibboleth IdP software and need to direct people to the correct one to process the login request. Load Balanced across three VMs, we now have six IdPs to manage 🙂

On top of all this, web based authentication uses our SimpleSAMLphp based local Identity Provider to provide SSO with the rest of local web services.

Mapping users

For long and complicated reasons, our users exist in one of the two domains and are mapped and redirected to the correct IdP by an Apache rewrite rule (see below) and some Microsoft pre-authentication magic:

  • kent.ac.uk: https://dan.kent.ac.uk/idp-a/shibboleth
  • kentforlife.net: https://dan.kent.ac.uk/idp-b/shibboleth

Authentication

The below diagram maps the process of logging in to Office365 for users.

O365 SSO Workflow

  1. User browses to https://live.kent.ac.uk
  2. HTTP 301 Redirect to https://dan.kent.ac.uk/r/
    • If user has locally active modmellon session then skip to 6
  3. Send user to https://sso.id.kent.ac.uk/idp/ to log in
  4. If necessary, user will be prompted to log in (they may already have an active session in which case this step is seamless)
  5. SSO service redirects back to /r/
    • Apache/modmellon is sent the unikentliveid in the assertion
  6. mod_rewrite looks at unikentliveid (format LOGIN@DOMAIN) and issues a Redirect to https://outlook.com/DOMAIN (see below)
  7. Microsoft’s infrastructure bounces around a bit then sends the user back to the correct IdP url (e.g. https://dan.kent.ac.uk/idp-b/profile/SAML2/POST/SSO)
    • If user has a valid session with modmellon then skip to 10
  8. modmellon saves the incoming POST data for later then redirects the user to https://sso.id.kent.ac.uk/idp/ to log in
  9. As the user already has a session there [4], user is transparently redirected back to dan.kent.ac.uk
  10. The original POST data is replayed and the request is passed into the IdP software within Tomcat along with the user’s login name from SAML
    • IdP looks up the user in LDAP and AD and constructs the appropriate SAML response for Microsoft
  11. User sent back to Office365 with ImmutableId (objectGUID from AD) and UserID (unikentliveid from LDAP)

ECP workflow

Much simpler 🙂

  1. User initiates contact with, for example, ActiveSync and provides a username (in the LOGIN@DOMAIN form) and password
  2. Microsoft’s federation services make a SOAP over HTTPS (on port 8443) request to the correct IdP on dan.kent.ac.uk using the local part of the supplied username (e.g. if ms1@kentforlife.net was supplied then use ms1) and password in HTTP Basic Auth (checked in Apache)
  3. dan.kent.ac.uk responds with a SAML assertion as above with ImmutableId (objectGUID from AD) and UserID (unikentliveid from LDAP)

Mod_rewrite magic for redirecting based on a modmellon attribute

RewriteCond %{ENV:MELLON_unikentliveid} @(kent.ac.uk|kentforlife.net)$
RewriteRule .* https://outlook.com/%1 [R]

Leave a Reply