IDP 3 Duo + Username/Password with user-opt-in forcing Duo
David Langenberg
davel at uchicago.edu
Mon Oct 12 14:58:13 EDT 2015
There's two cases here:
1) SP doesn't request a context & you want to opt-in to forcing duo. The way that works is by removing the Password context from the list of contexts returned from the attribute resolver.
2) SP explicitly requests duo. I'd guess the issue there is that context-check. As Scott previously mentioned, you don't need that intercept check setup for this use-case and should remove all of that config. That intercept-predicate stuff is supposed to assist with dealing with the fact that @ uchicago, Password = Silver for users who have Silver. Duo doesn't come into play in that case.
Dave
On Oct 12, 2015, at 12:30 PM, Llosa, Tulio C <tllos1 at uis.edu<mailto:tllos1 at uis.edu>> wrote:
I have been struggling to get MFA-Duo working for the past couple weeks, and I’d appreciate any assistance in pointing out where I should be looking to make changes.
The IDP idp-process.log file shows that the attribute assurance (idp.authn.resolveAttribute = assurance) has 4 values:
2015-10-12 13:09:23,723 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] - Attribute Definition 'assurance': produced an attribute with the following values [StringAttributeValue{value=urn:oasis:names:tc:SAML:2.0:ac:classes:Password}, StringAttributeValue{value=http://id.incommon.org/assurance/bronze}, StringAttributeValue{value=http://id.incommon.org/assurance/silver}, StringAttributeValue{value=http://uis.edu/duo}]
However, the Potential authentication flows left after filtering only retain authn/Password and NOT authn/Duo:
2015-10-12 13:09:23,727 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByAttribute:134] - Profile Action FilterFlowsByAttribute: Retaining flow authn/Password, matched custom Principal urn:oasis:names:tc:SAML:2.0:ac:classes:Password
2015-10-12 13:09:23,728 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByAttribute:146] - Profile Action FilterFlowsByAttribute: Potential authentication flows left after filtering: {authn/Password=AuthenticationFlowDescriptor{flowId=authn/Password, supportsPassive=true, supportsForcedAuthentication=true, lifetime=3600000, inactivityTimeout=1800000}}
Where should I be looking to figure out why authn/Duo is not being considered a potential authentication flow? Is it in the global.xml bean definition or in the context-check-intercept-config.xml, or elsewhere?
Any help would be appreciated!
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Llosa, Tulio C
Sent: Wednesday, September 30, 2015 1:56 PM
To: users at shibboleth.net<mailto:users at shibboleth.net>
Subject: IDP 3 Duo + Username/Password with user-opt-in forcing Duo
Hello,
I followed the document Replicating Multi-Context Broker Functionality (Duo + Username/Password with user-opt-in forcing Duo): https://wiki.shibboleth.net/confluence/pages/viewpage.action?pageId=20807829
My problem is that I can't get the Duo Security service page to come up as a secondary authentication.
The SP configured for two-factor authentication shibboleth2.xml has:
authnContextClassRef="http://uis.edu/duo"
The error I get on the browser after authenticating with username/password is:
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Requester
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
Message: An error occurred.
All other SP's (without the Duo authnContextClassRef) authenticate successfully using username/password.
My configuration is as follows:
On the IDP side:
Steps 1,2: Same as the wiki page above
Step 3: $IDP_HOME/conf/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://uis.edu/duo" />
<bean parent="shibboleth.SAML1AuthenticationMethod"
c:method="http://uis.edu/duo" />
</util:list>
</property>
</bean>
Step 4: Completed. shib-extensions.jar built and copied to $IDP_HOME/edit-webapp/WEB-INF/lib/
Step 5: $IDP_HOME/conf/attribute-resolver.xml
Static attribute "assurance" with values "urn:oasis:names:tc:SAML:2.0:ac:classes:Password" and "http://uis.edu/duo" for everyone for now. Eventually it will be a scripted attribute that sets the password context for everyone and adds the Duo context if a user is a member of the DUO LDAP group.
Step 6: Same as wiki except idp.authn.resolveAttribute = assurance
Step 7: $IDP_HOME/conf/authn/authn-comparison.xml
<bean id="shibboleth.BetterClassRefMatchFactory" parent="shibboleth.InexactMatchFactory">
<property name="matchingRules">
<map>
<entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:Password">
<list>
<value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
<value>http://uis.edu/duo</value<http://uis.edu/duo%3c/value>>
</list>
</entry>
<entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
<list>
<value>http://uis.edu/duo</value<http://uis.edu/duo%3c/value>>
</list>
</entry>
</map>
</property>
</bean>
Step 8: $IDP_HOME/conf/intercept/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:authnClassesToForgive-ref="authnClassesToForgive"
c:predicateToDelegate-ref="attributePredicate" />
</list>
</constructor-arg>
</bean>
<util:set id="authnClassesToMatch">
<value>http://uis.edu/duo</value<http://uis.edu/duo%3c/value>>
</util:set>
<util:set id="authnClassesToForgive">
<value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
</util:set>
<bean id="attributePredicate" class="net.shibboleth.idp.profile.logic.SimpleAttributePredicate">
<property name="attributeValueMap">
<map>
<entry key="assurance">
<list>
<value>http://uis.edu/duo</value<http://uis.edu/duo%3c/value>>
</list>
</entry>
</map>
</property>
</bean>
What am I missing?
Thanks in advance.
Tulio
The idp-process.log shows:
2015-09-30 13:20:13,480 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] - Attribute Definition 'assurance': produced an attribute with the following values [StringAttributeValue{value=urn:oasis:names:tc:SAML:2.0:ac:classes:Password}, StringAttributeValue{value=http://uis.edu/duo}]
2015-09-30 13:20:13,483 - DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:432] - Attribute Resolver 'ShibbolethAttributeResolver': Attribute 'assurance' has 2 values after post-processing
2015-09-30 13:20:13,483 - DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:206] - Attribute Resolver 'ShibbolethAttributeResolver': Final resolved attribute collection: [assurance]
2015-09-30 13:20:13,502 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByAttribute:134] - Profile Action FilterFlowsByAttribute: Retaining flow authn/Password, matched custom Principal urn:oasis:names:tc:SAML:2.0:ac:classes:Password
2015-09-30 13:20:13,502 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByAttribute:146] - Profile Action FilterFlowsByAttribute: Potential authentication flows left after filtering: {authn/Password=AuthenticationFlowDescriptor{flowId=authn/Password, supportsPassive=true, supportsForcedAuthentication=true, lifetime=3600000, inactivityTimeout=1800000}}
2015-09-30 13:20:13,507 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:341] - Profile Action SelectAuthenticationFlow: Specific principals requested with 'exact' operator: [AuthnContextClassRefPrincipal{authnContextClassRef=http://uis.edu/duo}]
2015-09-30 13:20:13,507 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:445] - Profile Action SelectAuthenticationFlow: Checking for an inactive flow or active result compatible with operator 'exact' and principal 'AuthnContextClassRefPrincipal{authnContextClassRef=http://uis.edu/duo}'
2015-09-30 13:20:13,508 - DEBUG [net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:80] - Registry located predicate factory of type 'net.shibboleth.idp.authn.principal.impl.ExactPrincipalEvalPredicateFactory' for principal type 'class net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal' and operator 'exact'
2015-09-30 13:20:13,509 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:475] - Profile Action SelectAuthenticationFlow: None of the potential authentication flows can satisfy the request
2015-09-30 13:20:13,514 - DEBUG [org.opensaml.saml.common.profile.logic.DefaultLocalErrorPredicate:184] - Error event RequestUnsupported will be handled with response
--
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/20151012/dd3597ed/attachment-0001.html>
More information about the users
mailing list