IDPv3 with ADFSv3 proxy

[Christopher Bland]

Hi All,

I have a legacy ADFSv3 server which proxies Office365.  After switching over to my new IDP (v3.4.4) I find I am having an issue with application based authentication.  I seems that when I login to the web interface the AuthnRequest look like this

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
    Destination="https://idp.fdu.edu/idp/profile/SAML2/Redirect/SSO"
    ID="id-2333c098-3bce-42fe-9a31-1bcddb688e92"
    IssueInstant="2019-08-16T10:05:32.091Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sso.fdu.edu/adfs/services/trust</Issuer>
    <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</samlp:AuthnRequest>

However, when Word, Excel, Teams, etc..  try to log in it looks like this

<samlp:AuthnRequest
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
    Destination="https://idp.fdu.edu/idp/profile/SAML2/Redirect/SSO"
    ForceAuthn="true" ID="id-4f135dfe-dfbd-4bb4-8a22-78cfac58b6a9"
    IssueInstant="2019-08-16T08:21:25.632Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sso.fdu.edu/adfs/services/trust</Issuer>
    <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
    <samlp:RequestedAuthnContext>
        <samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</samlp:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Which causes my IDP to - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:408] - Profile Action SelectAuthenticationFlow: Forced authentication requested, selecting an inactive flow

I have read a few posts and looked at the v2 MicrosoftInterop<https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop> docs where the solution was to create a handler just for ADFS.  On person posted changing the Password handler like this as to add the context but Scott noted “that would make it the *only* method”.

        <bean id="authn/Password" parent="shibboleth.AuthenticationFlow"
                p:passiveAuthenticationSupported="true"
                p:forcedAuthenticationSupported="true" >
           <property name="supportedPrincipals">
               <list>
                    <bean parent="shibboleth.SAML2AuthnContextClassRef"
                        c:classRef="http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password" />
                </list>
           </property>

        </bean>

In a similar post where the poster was dealing with MFA the poster referenced the v2 MicrosoftInterop doc and not wanting to create a sperate handler.  In that thread Scott posted

I haven't done that, and I haven't supported any of their made up attributes. It's been pretty much vanilla integrations for me on campus. I also have a variety of vendors using ADFS and none of them have ever issued requests with a non-standard context class.

Basically, you can treat ADFS like any other SP for the most part.

So my question is this:  in the AuthenticationFlowSelection<https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection> doc it mentions in the Comparison Configuration section that I can ignore context. Is the best method to deal with this to. create a ignore rule like below and does it work like I think it does and turns my application based AuthnRequest into regular authn/Password requests?

    <util:list id="shibboleth.IgnoredContexts">
        <value>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</value>
        <value> http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password </value>
    </util:list>

What are other institutions doing?

-Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190816/fd814eff/attachment.html>