IdP3 Force Authentication Context for select CAS services

[Cantor, Scott]

On 7/21/17, 12:00 PM, "users on behalf of Mak, David" <users-bounces at shibboleth.net on behalf of d.mak at northeastern.edu> wrote:

> Thank you Scott, for the quick reply. I went ahead and modified the Unicon configuration file META-INF/shibboleth- 
> idp/conf/global.xml to be as follows, replacing http://www.duosecurity.com/ with urn:duosecurity:

I wasn't suggesting the string was physically wrong. And urn:duosecurity is not a real URN. You can't just make them up.

Separately from your issue, I urge you to define a value for MFA that is technology neutral and is minted by you for your purposes, or see if you comply with InCommon's MFA profile and perhaps use that.

But the issue I was raising was the syntax, rather than the value. I was saying that I don't think you should be using this:

> p:defaultAuthenticationMethods="urn:duosecurity"

That is NOT the value type for that property. If it works, ok, but I bet it breaks at some point.

The value is a collection of AuthnContextClassRefPrincipal objects, much like with the descriptor beans themselves in the other file, so you should specify them as such, using a <list> element containing bean definitions. I realize that's uglier, but it is what's correct. I don't even know how Spring is managing to do that conversion, and depending on that is a bad idea.

> So, it shows the relying party group is being resolved properly. I just don’t seem to get any action on the 
> defaultAuthenticationMethods parameter.

I don't think that's physically possible based on the code, but all I can suggest is to file a bug. I don't anticipate it being reproducible, but anything's possible.

> Any suggestions to how I can debug this further would be appreciated.

The logs during authentication will show what it thinks the request specifies if anything. If it says that there are no special authentication requirements to evaluate, then there's no way it can be using that relying party config.

-- Scott