idp auth module plugin

[Cantor, Scott]

On 7/20/22, 2:33 AM, "dev on behalf of Paul Henson" <dev-bounces at shibboleth.net on behalf of henson at signet.id> wrote:

>    Every other decision involved is based on configuration on the server side:

The problem with that is you can't implement policies that vary by service and that's pretty much a day 2 requirement, if not day 1. In fact, you might even immediately get asked to fill the gap, by imposing policy locally on the methods allowed for the user based on the service or other criteria, i.e. what ever other vendor I think provides themselves. I guess that might be a value-add, but I would wonder if that's something they give you if you use their service natively instead of fronting it.

>    I'm sure I'm missing something as to why this is more complicated or 
>    difficult within the Spring framework, but why couldn't I just create a 
>    new cookie store:

Assuming that's the HttpClient class for managing them...

>    	CookieStore cookieStore = new BasicCookieStore();
>
>    persist it in the authentication context, and tell the client to use it 
>    before I make each call?
>
>    	httpClient.setCookieStore(cookieStore);

Because the normal model is for a singleton HttpClient shared by the system, and the lack of synchronization there would break it. You could of course just create the client on the fly inside the code instead of using a singleton, but that also doesn't perform as well due to the lack of connection pooling and so forth.

I would expect though that the cookie management injection point would be into the HttpClient "context" used for each call, so that it wouldn't be shared, not injected into the client directly, unless of course the cookie store itself is somehow multi-thread aware.

Again, don't know any of this, we don't do anything with cookies to this point in any places we use the clients, every call is assumed to be independent. We didn't implement anything like OAuth/token-based authentication for the HTTPConnector or anything like that, or it would have become a problem.

>    But basically it starts off initializing the flow, creating the 
>    authentication context, checking for options and property/headers or 
>    cookies, and then checking if there is already a username associated 
>    with the request.

If you mean our AuthenticationContext class, that's handled already by the authn flow, it's not something login flows create. They might have a subcontext they use for themselves of course, but the main one is there already.

>    I'm not sure how using subflows for it would work, as from the top level 
>    flow you might jump to the password form or to the password processing, 
>    or to the TOTP form or directly to processing. It would depend on 
>    whether or not the user sent the necessary authentication information in 
>    headers for non-browser authentication.

Subflows just keep the behavior more organized and modular, and sometimes a little easier to understand the flow overall. Same as functions in any other procedural language.

-- Scott