MCB in IDP 3

[David Langenberg]

Ok, now, make the resolver return PasswordProtectedTransport if not Duo.

Dave

On Sep 9, 2015, at 12:57 PM, Hong Ye <hy93 at cornell.edu<mailto:hy93 at cornell.edu>> wrote:

Hi Dave,

Thank you very much for your advice. I removed step 8 and modified resolver to return nothing if user not opt-in DUO that resolved the case #2. But case #1 still doesn’t work.

Hong


On Sep 9, 2015, at 2:18 PM, David Langenberg <davel at uchicago.edu<mailto:davel at uchicago.edu>> wrote:

The idea behind step 8 is to assist with the fact that Password => Silver for us.  I don't believe step 8 is necessary in your case.  As for your attribute-resolver, we don't ever return :unspecified from the resolver.  The results for the default case are always the PasswordProtectedTransport class.  The IdP treats :unspecified very different than any other context class, so I'd try first fixing your resolver and seeing if that helps any.

Dave

On Sep 9, 2015, at 11:32 AM, Hong Ye <hy93 at cornell.edu<mailto:hy93 at cornell.edu>> wrote:

Hi,

I did similar configuration as described in https://wiki.shibboleth.net/confluence/pages/viewpage.action?pageId=20807829. Our IDP use Remote User as primary log in so I made some changes in the configuration. It works as expected if the AuthnContextClass was not sent in the AuthnRequest or AuthnContextClassRef specified in the AuthnRequest is the same as the resolved value of eduPersonAssurance. Otherwise it didn’t work.

Case 1:

if remoteUser class ref is specified in AuthnContextClassRef of AuthnRequest, but user opt in in DUO. After primary authentication, IDP sent back  error status

<saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext" />
        </saml2p:StatusCode>
    <saml2p:StatusMessage>authn</saml2p:StatusMessage>
</saml2p:Status>

Right now I don’t care about user should be promoted for DUO or not in this case. But I don’t expect IDP sent back error status.

Case 2:
If duo class ref is specified in AuthnContextClassRef of AuthnRequest, but user doesn’t opt in in DUO. After primary authentication, user was prompted for DUO. Even though user finished DUO authentication, IDP still sent back error status.


<saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext" />
        </saml2p:StatusCode>
    <saml2p:StatusMessage>authn</saml2p:StatusMessage>
</saml2p:Status>

In this case, I think DUO should be prompted no matter user opt in or not. But IDP shouldn’t send back error status after successful DUO login.

Here are all the steps I did:
Step1,2 exactly the same as the wiki page
Step  3: global.xml
 <bean id="authn/Duo" parent="shibboleth.AuthenticationFlow"
          p:nonBrowserSupported="false" p:forcedAuthenticationSupported="%{duo.forcedAuthenticationSupported:true}">
        <property name="supportedPrincipals">
            <util:list>
                <bean parent="shibboleth.SAML2AuthnContextClassRef"
                      c:classRef="http://cornell.edu/duo" />
                <bean parent="shibboleth.SAML1AuthenticationMethod"
                      c:method="http://cornell.edu/duo" />
            </util:list>
        </property>
 </bean>
Step 4
Step 5. attribute-resolver.xml

Value "http://cornell.edu/duo”<http://cornell.edu/duo%E2%80%9D> is returned for eduPersonAssurance when user opt in DUO
Otherwise ""urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified”

step 6: same
Step 7: authn-comparison.xml
<bean id="shibboleth.BetterClassRefMatchFactory" parent="shibboleth.InexactMatchFactory">

        <property name="matchingRules">
            <util:map>
                <entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified">
                    <list>
                        <value>http://cornell.edu/duo</value><http://cornell.edu/duo%3C/value%3E>
                    </list>
                </entry>
            </util:map>
        </property>

    </bean>

Step 8 context-check-intercept-config.xml

<bean id="shibboleth.context-check.Condition" parent="shibboleth.Conditions.AND">
        <constructor-arg>
            <list>
                <bean class="net.shibboleth.idp.profile.logic.AuthnClassPredicate"
                    c:authnClassesToMatch-ref="authnClassesToMatch"
                    c:predicateToDelegate-ref="attributePredicate" />
            </list>
        </constructor-arg>
    </bean>

    <util:set id="authnClassesToMatch">
        <value>http://cornell.edu/duo</value><http://cornell.edu/duo%3C/value%3E>
    </util:set>

   <bean id="attributePredicate" class="net.shibboleth.idp.profile.logic.SimpleAttributePredicate">
      <property name="attributeValueMap">
          <map>
             <entry key="eduPersonAssurance">
                 <list>
                    <value>http://cornell.edu/duo</value><http://cornell.edu/duo%3C/value%3E>
                 </list>
             </entry>
          </map>
      </property>
   </bean>

Anything wrong with the configuration?

Thanks,
Hong
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

--
David Langenberg
Identity & Access Management Architect
The University of Chicago



--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

--
David Langenberg
Identity & Access Management Architect
The University of Chicago



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