MCB in IDP 3

[Cantor, Scott]

On 9/9/15, 1:32 PM, "users on behalf of Hong Ye" <users-bounces at shibboleth.net on behalf of hy93 at cornell.edu> wrote:


>
>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.

If the SP requests something and the resolved attribute value is applied to filter out login flows and there's no overlap, you would end up with no flows, and no way for the IdP to do anything, it should log that no login flows were acceptable for the user.

The *only* thing the resolved attribute does right now is filter the flows to run up front. But on the surface what you're describing is what I would expect, depending on specifics.

>Case 1:
>
>if remoteUser class ref is specified in AuthnContextClassRef of AuthnRequest, but user opt in in DUO.

Right now I think there are a number of complications making that kind of opt-in work, but I guess David has come up with workarounds for a lot of them.

I don't really know what it even means. Opt-in might mean "chooses to always use" or it might mean "indicates they can use". Seems like a big difference. It's messy either way.

> After primary authentication, IDP sent back  error status

The status code means that the methods available for the user after possibly filtering out some of them don't support the context class Principal object corresponding to what the SP sent. NoAuthnContext means that it couldn't do what the SP asked for with the methods it knows about.

>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.

Don't know what to say to that, this is so complex I can't really follow it. You need to look at the logs and see what it's doing.

Also, there is no such thing as "primary authentication". I don't know what that means, which makes it hard to follow along.

But the error code is the same, so the same problem was involved. It couldn't satisfy the request.

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

As David said, you cannot use that value.

>Step 8 context-check-intercept-config.xml

I'm not sure what that part is being used for. The IdP is meant to be handling whether a login satisfies a request or not, separately from any attribute checking. Having it look at an attribute that's meant to be about what a user might be able to do initially, and not what they actually did do, will do some pretty strange things I think.

I also don't understand the intent behind the condition.

><bean id="shibboleth.context-check.Condition" parent="shibboleth.Conditions.AND">
>        <constructor-arg>
>            <list>
>                <bean class="net.shibboleth.idp.profile.logic.AuthnClassPredicate"

That is not a class I recognize, and you definitely CANNOT create classes in our packages. I think you got that from David, but that's a mistake, it should be a custom package name to avoid a conflict. If it's useful of course, we can add it to the API.

But that aside, I don't follow what that's all supposed to be doing and I don't know whether you should be doing it. I would be very wary of that.

-- Scott