To provide a little context, our existing student email provision is fulfilled by Microsoft’s Live@EDU service. Some time ago, we were informed that we would be being upgraded to Office365 for Education.

A major change, from a functionality point of view, as a result of this move is that the old method of replicating passwords from our on-site Active Directory system to the Live@EDU identity would no longer be available – bummer! However we would, instead, be able to Federate our local identities instead using either Microsoft Active Directory Federation Services (ADFS) or Shibboleth. Of these two our first choice is Shibboleth as we already understand and use it and we do not have any ADFS infrastructure or expertise.

In attempting to implement a federated relationship between our local Shibboleth infrastructure (behind which is a SunOracle Directory Server (DSEE) platform and Active Directory) we have hit numerous bumps along the way. To summarise, Microsoft’s implementation of SAML2 seems to be rather new.

Pockets of the support teams seem to be pretty good and understand that ADFS isn’t the only way, however they can be hard to find!

As of now, browser based SSO is working but ECP (ActiveSync etc) isn’t… SAML assertions going out here and being refused at the other end. It was working last week, then it stopped working, then it started working again and now it’s broken again. Support call open…

Documentation

The Microsoft documentation available for configuring an Office365 domain to federate with an existing Shibboleth instance seems pretty good. They have produced pages and pages of information on Technet and also released a formal whitepaper on the subject.

The available documentation seems to assume that you’ll be running your Shibboleth Identity Provider on Windows but that shouldn’t make a difference in the long run – it’s just a java application inside Apache Tomcat, after all… right?

Issues encountered so far

Some fairly fundamental issues became apparent while testing the implementation:

1. The published SAML2 metadata is incomplete
2. The Shibboleth IdP should be using a real SSL certificate for ECP (which extends the SAML2 model to allow a non-browser based authentication flow thus enabling the use of other protocols such as IMAP and ActiveSync) to work
3. The diagnostics available are not great (on the web) or nonexistent (for ECP)
4. There seems to be an assumption that your Shibboleth IdP won’t be being used for anything else (and will be running on Windows)

SAML2 Metadata incomplete

While following the instructions on Technet to Add Windows Azure AD metadata everything seems to be in order. When coming to test ECP functionality, it became apparent that the metadata available from the published HTTPS endpoint (https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml) was different from the metadata included in the Technet article explaining how it works – it was missing the information requires to make ECP work… the binding configuration.

A quick fix is to not configure the IdP to download the metadata from Microsoft (as they suggest) but, instead, hard code the metadata as included in the Technet article:

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:federation:MicrosoftOnline">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0" isDefault="true"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://login.microsoftonline.com/login.srf" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf" index="2" />
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    </NameIDFormat>
    <NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    </NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

So our current configuration in relying-party.xml is:

<!-- Azure for Office 365 -->
<MetadataProvider id="AzureLocal" xsi:type="FilesystemMetadataProvider"
 xmlns="urn:mace:shibboleth:2.0:metadata"
 metadataFile="/opt/idp/metadata/azure-metadata.xml">
 <MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata">
   <MetadataFilter xsi:type="EntityRoleWhiteList" xmlns="urn:mace:shibboleth:2.0:metadata">
     <RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
   </MetadataFilter>
 </MetadataFilter>
</MetadataProvider>

SSL certificates for ECP

Despite being explicitly told what trust fabric certificate to trust (when configuring the federation settings via the Set-MsolDomainAuthentication powershell command), the Microsoft SP will refuse to communicate with an HTTPS endpoint using an untrusted (or, in our case, self-signed) certificate.

Diagnostics

When attempting to diagnose browser logon issues, the only error that a user normally sees is “Your organization could not sign you in to this service”. Not entirely helpful. As it happens, there’s an error code buried in the HTML source of the page. Details of how to extract this are available here.

As for ECP related issues, there doesn’t appear to be a method of diagnosing a problem. The remote service just refuses to authenticate claiming, in the case of the nice and simple POP3, “unknown user name or bad password”.

+OK The Microsoft Exchange POP3 service is ready.
USER user@federated.domain
+OK
PASS password
-ERR Logon failure: unknown user name or bad password.

Helpful.

More to follow, methinks.