{"id":5,"date":"2013-02-05T10:49:11","date_gmt":"2013-02-05T10:49:11","guid":{"rendered":"http:\/\/blogs.kent.ac.uk\/unseenit\/?p=5"},"modified":"2013-10-18T08:07:42","modified_gmt":"2013-10-18T08:07:42","slug":"office365-and-shibboleth","status":"publish","type":"post","link":"https:\/\/blogs.kent.ac.uk\/unseenit\/office365-and-shibboleth\/","title":{"rendered":"Office365 and Shibboleth"},"content":{"rendered":"

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\u00a0upgraded<\/em> to Office365 for Education<\/a>.<\/p>\n

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 \u2013 bummer! However we would, instead, be able to Federate our local identities instead using either Microsoft Active Directory Federation Services<\/a> (ADFS) or Shibboleth<\/a>. 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.<\/p>\n

In attempting to implement a federated relationship between our local Shibboleth infrastructure (behind which is a Sun<\/del>Oracle Directory Server (DSEE) platform and Active Directory) we have hit numerous bumps along the way. To summarise, Microsoft’s implementation of SAML2<\/a> seems to be rather\u00a0new<\/em>.<\/p>\n

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!<\/p>\n

As of now, browser based SSO is working but ECP (ActiveSync etc) isn’t\u2026 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\u2026<\/p>\n

Documentation<\/h1>\n

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<\/a> and also released a formal whitepaper<\/a> on the subject.<\/p>\n

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 \u2013 it’s just a java application inside Apache Tomcat, after all\u2026 right?<\/p>\n

Issues encountered so far<\/h1>\n

Some fairly fundamental issues became apparent while testing the implementation:<\/p>\n

    \n
  1. The published SAML2 metadata is incomplete<\/span><\/li>\n
  2. The Shibboleth IdP should be using a\u00a0real<\/em>\u00a0SSL certificate for ECP<\/a>\u00a0(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)\u00a0to work<\/li>\n
  3. The diagnostics available are not great (on the web) or nonexistent (for ECP)<\/li>\n
  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)<\/li>\n<\/ol>\n

    SAML2 Metadata incomplete<\/h2>\n

    While following the instructions on Technet to\u00a0Add Windows Azure AD metadata<\/a>\u00a0everything 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<\/a>) was different from the metadata included in the Technet article explaining how it works \u2013 it was missing the information requires to make ECP work\u2026 the\u00a0binding<\/em>\u00a0configuration.<\/p>\n

    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:<\/p>\n

    <?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n<EntityDescriptor xmlns=\"urn:oasis:names:tc:SAML:2.0:metadata\" entityID=\"urn:federation:MicrosoftOnline\">\r\n  <SPSSODescriptor WantAssertionsSigned=\"true\" protocolSupportEnumeration=\"urn:oasis:names:tc:SAML:2.0:protocol\">\r\n    <AssertionConsumerService Binding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\" Location=\"https:\/\/login.microsoftonline.com\/login.srf\" index=\"0\" isDefault=\"true\"\/>\r\n    <AssertionConsumerService Binding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign\" Location=\"https:\/\/login.microsoftonline.com\/login.srf\" index=\"1\"\/>\r\n    <AssertionConsumerService Binding=\"urn:oasis:names:tc:SAML:2.0:bindings:PAOS\" Location=\"https:\/\/login.microsoftonline.com\/login.srf\" index=\"2\" \/>\r\n    <NameIDFormat>\r\n      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\r\n    <\/NameIDFormat>\r\n    <NameIDFormat>\r\n      urn:mace:shibboleth:1.0:nameIdentifier\r\n    <\/NameIDFormat>\r\n    <NameIDFormat>\r\n      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\r\n    <\/NameIDFormat>\r\n    <NameIDFormat>\r\n      urn:oasis:names:tc:SAML:2.0:nameid-format:transient\r\n    <\/NameIDFormat>\r\n    <NameIDFormat>\r\n      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent\r\n    <\/NameIDFormat>\r\n  <\/SPSSODescriptor>\r\n<\/EntityDescriptor><\/pre>\n
    So our current configuration in relying-party.xml is:<\/p>\n
    <!-- Azure for Office 365 -->\r\n<MetadataProvider id=\"AzureLocal\" xsi:type=\"FilesystemMetadataProvider\"<\/span>\r\n xmlns=\"urn:mace:shibboleth:2.0:metadata\"\r\n metadataFile=\"\/opt\/idp\/metadata\/azure-metadata.xml\">\r\n <MetadataFilter xsi:type=\"ChainingFilter\" xmlns=\"urn:mace:shibboleth:2.0:metadata\">\r\n   <MetadataFilter xsi:type=\"EntityRoleWhiteList\" xmlns=\"urn:mace:shibboleth:2.0:metadata\">\r\n<\/span>     <RetainedRole>samlmd:SPSSODescriptor<\/RetainedRole>\r\n   <\/MetadataFilter>\r\n <\/MetadataFilter>\r\n<\/MetadataProvider><\/pre>\n
    SSL certificates for ECP<\/h2>\n
    Despite being explicitly told what trust fabric certificate to trust (when configuring the federation settings via the Set-MsolDomainAuthentication<\/code>\u00a0powershell command), the Microsoft SP will refuse to communicate with an HTTPS endpoint using an\u00a0untrusted<\/em> (or, in our case, self-signed) certificate.<\/p>\n
    Diagnostics<\/h2>\n
    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<\/a>.<\/p>\n
    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\u00a0nice and<\/em> simple POP3, “unknown user name or bad password”.<\/p>\n
    +OK The Microsoft Exchange POP3 service is ready.\r\nUSER user@federated.domain\r\n+OK\r\nPASS password\r\n-ERR Logon failure: unknown user name or bad password.<\/pre>\n
    Helpful.<\/p>\n
    More to follow, methinks.<\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    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 … Read more<\/a><\/p>\n","protected":false},"author":13,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[28933],"tags":[28923,862,28920,28922,119],"_links":{"self":[{"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/posts\/5"}],"collection":[{"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/comments?post=5"}],"version-history":[{"count":9,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/posts\/5\/revisions"}],"predecessor-version":[{"id":36,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/posts\/5\/revisions\/36"}],"wp:attachment":[{"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/media?parent=5"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/categories?post=5"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/unseenit\/wp-json\/wp\/v2\/tags?post=5"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}