idp 4 upgrade, tuning MFA implementation

[Cantor, Scott]

On 4/24/20, 4:49 PM, "users on behalf of Paul B. Henson" <users-bounces at shibboleth.net on behalf of henson at cpp.edu> wrote:

>> My way of doing this is generally to carefull stick to making sure that the
>> resulting Principal set in each result always accurately reflects what methods
>> the user did
>
> Ah, ok. How does one make sure of such a thing :)?

The general-authn.xml file lays out the Principals that are auto-attached in most cases to the Subject created by the authentication flows of each type. When those are correct, the individual results generated will be indicative of what was done, and the MFA result merges all of them together when it produces the composite Subject.

When you have Password and Duo, the Principals in each case should be distinct, and checking the Subject for whether it carries the Duo-specific AuthnContextClassRefPrincipal is a signal for whether it happened or not. You have to iterate over the Principals of a given type and look for matching strings.

The Subject of the MFA result is going to be sitting inside the AuthenticationContext, via getActiveResults(), which is a map from login flow name to result. PRC -> AuthenticationContext -> getActiveResults("authn/MFA").getSubject()

By definition that has to be there because it's asking whether to reuse the MFA flow result if it's running the reuseCondition.

> Should I start digging into net.shibboleth.idp.authn? Or maybe it's in net.shibboleth.idp.authn.principal, or
> net.shibboleth.idp.authn.principal.impl, or one of a number of other classes that sound promising.

Everything that isn't "impl" is an API package. And the place to start are the context objects that make up the tree, primarily the ProfileRequestContext, AuthenticationContext, RelyingPartyContext, AttributeContext, etc. All the contexts tend to be in their own packages and the fields in them contain the important objects in the API. The AuthenticationContext has fields for a ton of information, the most important being the AuthenticationResult when you're talking about a reuse scenario. There obviously is no result prior to that.

Once you're into MFA, you're another layer down, and have to look at the MultiFactorAuthenticationContext, if you want to get at individual results from the composite methods.

> There are various examples of scripts in the configuration documentation, but am I missing someplace that has a more
> general description of how to configure them and how to navigate around the various pieces to get to the data you
> need?

I think the documentation on developing login flows is the best material there is.

https://wiki.shibboleth.net/confluence/display/IDP4/Authentication

> and compare it to the ID of the relying party override? I don't see an explicitly provided ID given in the override syntax
> though? Where does that value come from?

You just have to add id="something" to the element. Those are native Spring beans, and beans always have an id, but if you don't give it one, it will just autocreate one. Look at the log and you'll see it mention them as the name of the override it assigned at runtime when the SP request is handled.

Our example should really have an id in it, I didn't notice that it doesn't.

-- Scott