idp auth module plugin

[Cantor, Scott]

On 8/2/22, 10:50 PM, "dev on behalf of Paul Henson" <dev-bounces at shibboleth.net on behalf of henson at signet.id> wrote:

>    Looking at other "authentication" things that aren't username and 
>    password, such as ValidateRemoteUser, ValidateUserAgentAddress, 
>    ValidateX509Certificate, and ValidateExternalAuthentication, they seem 
>    to be based on AbstractValidationAction? Would that be a better choice
>  for my module?

I suspect. TOTP is a single transaction that looks like a password. It's self-contained. Why I decided to do that was probably as much to determine if it would work as anything else.

You have a bunch of different methods to implement, and you don't have any obvious way to chain them together as validators inside a single ValidateCredentials action bean, so it's just going to end up with more code and wiring in the end.

>    They seem to use a mix of ActionSupport.buildEvent and handleError for 
>    failure conditions.

handleError invokes the error message mapping logic so that views rendered afterward can get classified errors to key off of. Many of the flows have no views to render so there is no error handling that matters, it just fails regardless of why and moves on.

>    That example is again taken from the TOTP module, in 
>    AbstractTOTPExtractionAction:

I think it had to do with the fact that there wasn't any need for message classification, so it's just brute forcing the logic but it probably shouldn't have. Note that the view also doesn't handle NoCredentials, because if it did, then the initial display of the view would end up thinking there was an error because the extraction of a code from an HTTP header would have failed already and signaled that event. So it ignores that case.

>    Ok, then for my purposes I should just generate events on error 
>    conditions in the Java code and hard code a proceed at the end of the 
>    evaluate list that will be used if nothing else generated anything?

That is the normal model. You can signal proceed from an action using the special method defined for that purpose for clarity but it won't actually do anything.

>    Is there any child class of it that would be more appropriate for 
>    wrapping the API calls to the rapid identity server?

I don’t know what they all do, but the ones that actually finalize the process would be validation actions. Things that extract credentials are extraction actions. There aren't really any other special types.

>    I'm doing it because you did it :), and the bundled TOTP module seemed 
>    like a good basis for this one. I'm definitely open to better options, 
>    whether it is AbstractValidationAction or something else.

I don't think your use case is anything like TOTP, you have multiple paths through the code with much more advanced UI than TOTP does. That plugin is nice for showing lots of things, but how to actually implement the logic probably isn't one of them.

>    By this you mean end state error events that bubble up, right? Not 
>    random internal events that control transitions within the flow like if
>   I make up ones such as RapidTOTPAuth or RapidAuthSelection to move
>  between my web flow states within the flow?

Yes, it's the end-states that have to be enumerated. But we tend to limit events to the ones we pre-defined, there are static classes in various places that define common events for SAML, the IdP, authentication, etc. It's usually not all that helpful to create lots of detailed custom events.

-- Scott