Page Comparison

...

• (OPTIONAL) When landing on the ADFS, the user will be presented with options to authenticate with either AD or Shibboleth. 
  • To automatically select Shibboleth over AD, we insert (or overwrite) a cookie into the incoming HTTP request with a Base64 value of the EntityID for the Shibboleth IdP
    • This is achieved in a load balancer or proxy performing man-in-the-middle for SSL.
    • That is, it decrypts the request, performs the manipulation, re-encrypt for the backend
    • There are many types of load balancer/proxy - this article will not go into any of their configuration - please use google with terms like "ssl offloading" and "set header/cookie" with the name of your load balancer/proxy.
  • Key: "MSISIPSelectionPersistent"
  • Value: "aHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vaWRwL3NoaWJib2xldGg=" (e.g. echo -n https://idp.example.com/idp/shibboleth | base64 )
  • There has recently been a bug with some mobile apps sending a query string that ADFS gets confused with Shibboleth's answer
    • if present in HTTP query: "wauth=http://schemas.microsoft.com/ws/", then set ADFS as login provider
    • Key: "MSISIPSelectionPersistent"
    • Value: "aHR0cHM6Ly9hZGZzLmV4YW1wbGUuY29tL2FkZnMvc2VydmljZXMvdHJ1c3Q=" (e.g. echo -n https://adfs.example.com/adfs/services/trust | base64 )
      

Access Control Service

Access Control Service does not support SAML, but supports the WS-Federation Web (passive) requestor profile, so can be used as an identity provider with the Shibboleth SP as described here.

Access Control Service does not appear to be able to understand metadata generated by the SP, or to generate metadata that the SP can understand, so you should be prepared to manually configure the SP's details in Access Control Service, and to hand-craft metadata for Access Control Service.

The configuration parameters you will need for Access Control Service are as follows.

• Realm should be the entity ID of the SP.
  
• Return URL should be the location of the appropriate assertion consumer service, typically something like https://sp.example.com/Shibboleth.sso/ADFS.
  
• Token format should be SAML 1.1.
  

Hand-crafted IdP metadata will look something like this. (Replace entity ID, signing key and SSO service location as appropriate.)

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://example.accesscontrol.windows.net/">
  <IDPSSODescriptor protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2003/07/secext">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>...base64 signing key...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <SingleSignOnService Binding="http://schemas.xmlsoap.org/ws/2003/07/secext"
        Location="https://example.accesscontrol.windows.net/v2/wsfederation"/>
  </IDPSSODescriptor>
</EntityDescriptor>

Attachments