Overriding authentication method for an SP

[Jim Fox]

In the MFA flow you could do a simple string compare on the relying-party entity id.
Jim

________________________________________
From: users <users-bounces at shibboleth.net> on behalf of Wessel, Keith <kwessel at illinois.edu>
Sent: Tuesday, December 13, 2016 9:15:23 AM
To: Shib Users
Subject: RE: Overriding authentication method for an SP

Thanks, Jim, but I'm looking for a way to force MFA for a particular SP that isn't able to request a specific authn context class, that being ADFS. It's a relying-party.xml change, I think, assuming that I can make that work with the new MFA flow.

I've found examples on the Shib wiki for assigning specific authn flows to a relying party in relying-party.xml, but I haven't found an example for the defaultAuthenticationMethods property yet using a list of principals. Still not sure what those values would look like. I'm looking for a bean name, I think, but I'm not sure which bean.

Keith

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Jim Fox
Sent: Monday, December 12, 2016 5:08 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Overriding authentication method for an SP

Here's the way we check for a particular requested principal.  This in a strategy bean.  If it would help I can post some of our 3.3 MFA config on the contrib page.

Jim

This checks to see if Token was requested.
---------------------

                  nextFlow = "authn/remoteuserplus";
                  authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                  rpCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.RequestedPrincipalContext");
                  if (rpCtx != null) {
                      rps = rpCtx.getRequestedPrincipals();
                      logger.debug("Specific principals requested with '{}' operator: {}", rpCtx.getOperator(), rpCtx.getRequestedPrincipals());
                      tkp = new AuthnContextClassRefPrincipal("urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken");
                      logger.debug("looking for '{}' aka '{}'", tkp.toString(), tkp.getName());
                      if ( rpCtx.getRequestedPrincipals().contains(tkp)) {
                        logger.debug("found");
                        nextFlow = "authn/remoteusertoken";
                      }
                  } else {
                      logger.debug("No specific principals requested");
                  }
               }


________________________________________
From: users <users-bounces at shibboleth.net> on behalf of Wessel, Keith <kwessel at illinois.edu>
Sent: Monday, December 12, 2016 2:38:31 PM
To: Shib Users
Subject: RE: Overriding authentication method for an SP

Liam was partially right. I was missing the double open and close curley brackets.

However, now I'm getting what Scott suggested I'd get: can't convert java.util.String to java.security.principal. I'll go digging for an example using a SAML2 authenticationContextClassRef.

So, yes, the docs are right.

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, December 12, 2016 4:29 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Overriding authentication method for an SP

On 12/12/16, 5:07 PM, "users on behalf of Liam Hoekenga" <users-bounces at shibboleth.net on behalf of liamr at umich.edu> wrote:

>    You might have a syntax error... our version looks like this...
>
>
>    p:defaultAuthenticationMethods="#{{'urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken'}}"

Is that working? I wouldn't expect it to, but Spring is weird at times. It's not really right.

> Our ADFS folks want Duo enabled for their Shib integration. Following the V3 relying party docs, I added this bean to my
> relying-party.xml:

That should not be what the docs say, the type of that property is List<Principal>. The values you need to supply aren't Strings, they're Principals, typically beans that inherit from shibboleth.AuthnContextClassRefPrincipal or shibboleth.AuthenticationMethodPrincipal (latter being SAML 1).

I've done examples that certainly show that approach, maybe there are some broken examples.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net