...
- 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
andhandler.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)/
by duplicating the unmodified Username/Password section, and then making modifications for the Microsoft authentication context. Both sections are shown below for completeness.conf/web.xml. Then modify web.xml
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 theweb.xml
. Also the<AuthenticationMethod>
was changed to the Microsoft context to match the<init-param>
section in theweb.xml
.
You will need to redeployidp.war
sinceweb.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 )
- 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
- 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)
- Cookie Enforcement
Code Block | ||
---|---|---|
| ||
# 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.
...