idp auth module plugin

[Cantor, Scott]

>    for various values of event id, other places call:
>
>    	errorHandler.handleError(profileRequestContext, authenticationContext,
>    	AuthnEventIds.INVALID_CREDENTIALS,
>    	AuthnEventIds.INVALID_CREDENTIALS);

That's part of the CredentialValidator interface, which is used for scenarios where you plug into the Password login flow. It's not used much of anywhere else. CredentialValidator plugins are not action beans so they use that API to signal errors back, where the surrounding code turns them into events. There are *no* cases where the authentication layer actually raises an exception to SWF itself deliberately that I know of. That's just not something we do. It's always an event.

>    if an error handler is available, and otherwise raise an exception:
>
>    	throw new LoginException(AuthnEventIds.NO_CREDENTIALS);

The action calling the CredentialValidator catches that, it's just a failsafe.

>    Some, but not all also call:
>
>    	recordFailure(profileRequestContext);

That's for metrics, it counts failed transactions. Nobody uses any of that but it's there.

>    Then occasionally there's this:
>
>    	authenticationContext.getSubcontext(AuthenticationErrorContext.class,
>    	true).getClassifiedErrors().add(AuthnEventIds.INVALID_CREDENTIALS);

That's not going to be very common, I'd have to know what's doing it to know why.

>    From what I can tell this is a way to map an event into a text message
>    on a view error screen? So you get something pretty like "The supplied
>    token code was invalid" instead of a generic error?

Probably a way of bypassing the logic that normally maps error messages into events, yes, to drive the example error handling in the login form (which again is only part of the Password flow).

>    From what I can tell ExtractTOTPFromHeader generates an event on
>    error, but no event on success? So if there's no event from the first
>    evaluate it falls over to the second which statically generates a
>    proceed event? Is there any reason it's done this way instead of
>    ExtractTOTPFromHeader calling:
>
>    	ActionSupport.buildProceedEvent(profileRequestContext)

Long story, it's not really worth going into, it had to do with how SWF handles empty return values from actions. If we had made the actions all return "proceed" or some other success string, every action would have had to be inside its own action-state instead of chained together. That's very verbose, and would be slower.

>    My plugin is going to have a number of classes derived from
>    AbstractAuthenticationAction

That more or less mostly just handles guaranteeing the AC exists and gets it passed into the overridden methods.

> and then one derived from
>  AbstractCredentialValidator.

Very unclear that's what you'd want to do, this isn't a password use case. You probably could, but I wouldn't lock into that approach, but the things you have to do to handle errors varies a lot depending on the layer you work at.

>  Is there any more comprehensive list
>  of those available for other scenarios like an https connection timing
>    out, or SSL cert validation failing, or invalid JSON being received from
>    a remote endpoint etc?

We don't want errors that are hugely specific unless they're actionable by the user in some way. If it fails, it fails, AuthenticationException is probably good enough.

The full list is by definition what's declared in the flow or its parent flows, and one way or another the master authn flow has to know how to deal with it, so adding completely new events is more or less not possible from a login flow. The list it handles is in idp-conf-impl/src/main/resources/net/shibboleth/idp/flows/authn/authn-abstract-flow.xml

>    Tnanks, and I'm sorry if I keep asking remedial level questions 8-/.

This is not a documented system, that takes extraordinary amounts of time and money, so like most open source, the code is the documentation. In this case, you have to know SWF very well to understand the code, and even then there are a lot of "-isms" particular to how it was used.

And on top of that, error handling is by far the hardest part of any design and usually the worst. In this cases, it's pretty awful.

-- Scott