MCB in IDP 3
Mark Boyce
Mark.Boyce at ucop.edu
Mon Nov 16 17:54:31 EST 2015
David,
Ah… thank you.
m.
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of David Langenberg
Sent: Monday, November 16, 2015 2:20 PM
To: Shib Users
Subject: Re: MCB in IDP 3
Hi Mark,
The user opting in/opting out is controlled by the values (in my config) expressed through eduPersonAssurance attribute. In my setup, a user opts-in to forcing duo for authentication by being placed in a grouper group such that when the ePA attribute is constructed the result is that the PasswordProtectedTransport authn class is no present on their entry. Since in the config Duo is configured as being equal / better than PPT the IdP will make the user attempt to complete the Duo login flow.
Dave
On Nov 16, 2015, at 2:59 PM, Mark Boyce <Mark.Boyce at ucop.edu<mailto:Mark.Boyce at ucop.edu>> wrote:
Dave,
Question regarding “opt-in”.. having gone through the dosc (https://wiki.shibboleth.net/confluence/pages/viewpage.action?pageId=20807829) and done a significant amount of testing, I see no option for a user to either opt-in or out of Duo when using a simple Password login… am I missing something?
Thanks,
Mark
Mark L. Boyce
Senior Identity Management Analyst
University of California, Office of the President
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of David Langenberg
Sent: Wednesday, September 09, 2015 11:59 AM
To: Shib Users
Subject: Re: MCB in IDP 3
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
--
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/20151116/d9637887/attachment-0001.html>
More information about the users
mailing list