Page Comparison

...

Load metadata for the ADFS system into the Shibboleth IdP.

Define a second login handler that is capable of responding to Microsoft's non-standard authentication context:

In this configuration, the IdP returns the MS authentication context when requested by ADFS, but returns the default PasswordProtectedTransport when a SP does NOT request the Microsoft authentication context. For this functionality, we duplicate the original (unmodified) Username/Password sections in web.xml and handler.xml and modify the duplicated sections to be specific to the Microsoft authentication context. Both configurations use the same Username/Password Login page, but the new section handles Microsoft authentication context, while the original section handles PasswordProtectedTransport (as well as no specific authentication method requested by the SP).

First, (if you haven't already done so) copy $(ANT_HOME)/src/main/webapp/WEB-INF/web.xml to $(IDP_HOME)/conf/web.xml. Then modify web.xml by duplicating the unmodified Username/Password section, and then making modifications for the Microsoft authentication context. Both sections are shown below for completeness.

Code Block

title	Example in web.xml

    <!-- In conf/web.xml -->
 
    <!-- Servlet for doing Username/Password authentication -->
    <servlet>
        <servlet-name>UsernamePasswordAuthHandler</servlet-name>
        <servlet-class>edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet</servlet-class>
        <load-on-startup>3</load-on-startup>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>UsernamePasswordAuthHandler</servlet-name>
        <url-pattern>/Authn/UserPassword</url-pattern>
    </servlet-mapping>
 
    <!-- Servlet for doing Username/Password MS authentication -->
    <servlet>
        <servlet-name>UsernamePasswordMSAuthHandler</servlet-name>
        <servlet-class>edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet</servlet-class>
        <load-on-startup>3</load-on-startup>
        <init-param>
          <param-name>authnMethod</param-name>
          <param-value>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</param-value>
        </init-param>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>UsernamePasswordMSAuthHandler</servlet-name>
        <url-pattern>/Authn/UserPasswordMS</url-pattern>
    </servlet-mapping>

In the new section above, <servlet-name> (in two places) and <url-pattern> were modified by adding "MS" to the text. Also, the <init-param> section was added to return the Microsoft authentication context by default.

Then modify $(IDP_HOME)/conf/handler.xml by duplicating the unmodified UsernamePassword <LoginHandler> section, and then make modifications for the Microsoft assurance <AuthenticationMethod> to the new UsernamePassword <LoginHandler> as follows. Both sections are shown below for completeness.

Code Block

title	Example in handler.xml

   <!-- In conf/handler.xml -->
 
    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                     jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">
        <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
    </ph:LoginHandler>
 
    <!--  Username/password MS authentication login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                     jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"
                     authenticationServletURL="/Authn/UserPasswordMS">
        <ph:AuthenticationMethod>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</ph:AuthenticationMethod>
    </ph:LoginHandler>

In the new section above, a new parameter "authenticationServletURL" was added to match the <url-pattern> entry in the web.xml. Also the <AuthenticationMethod> was changed to the Microsoft context to match the <init-param> section in the web.xml.

You will need to redeploy idp.war since web.xml has been modified.

Add an allow rule to attribute-filter.xml allowing the release of your username identifier. In this example, uid is used (urn:oid:0.9.2342.19200300.100.1.1).
Add your Shibboleth IdP as a Claim Provider to ADFS with powershell.
(OPTIONAL): If you would like your IDP to be the default provider install IIS Url Rewrite and add an inbound rule on the Default Web Site's /adfs/ls directory.
- Request URL: Matches the Pattern
- Using: Wildcards
- Pattern: "*"
- Action Rewrite
- Rewrite URL:
```
{R:0}?whr=https://yourentityid/idp/shibboleth
```
- Check Append query string
- Save the rule
- Execute the following code block on the ADFS server.

...

(OPTIONAL) When landing on the ADFS, the user will be presented with options to authenticate with either AD or Shibboleth.
- Cookie Enforcement
  - 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 )
- Per Relying-Party enforcement
  - You can specify which Claim Provider a Relying Party must use (if nothing is set, that is when the user is asked to select from the full list of providers)

Code Block

language	powershell

# Determine the Name of the Claims Provider you want to use
> Get-AdfsClaimsProviderTrust | ft Name, Identifier
 
Name             Identifier
----             ----------
Active Directory AD AUTHORITY
Shibboleth IdP   https://example.com/idp/shibboleth


# Determine the Identifier of the Relying Party you want to use
>Get-AdfsRelyingPartyTrust | Format-Table Identifier, ProtocolProfile, ClaimsProviderName
 
Identifier                                                                     ProtocolProfile ClaimsProviderName
----------                                                                     --------------- ------------------
{https://sp.example.com}                                                       WsFed-SAML      {}
{urn:ms-drs:adfs.example.com}                                                  WsFed-SAML      {Active Directory}
{https://login.microsoftonline.com/extSTS.srf, urn:federation:MicrosoftOnline} WsFed-SAML      {Shibboleth IdP}




# Set it
Get-AdfsRelyingPartyTrust -Identifier:'https://sp.example.com' | Set-AdfsRelyingPartyTrust -ClaimsProviderName:@('Shibboleth IdP')

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.

...

Versions Compared

Old Version 34

New Version 35

Key

Access Control Service