idp auth module plugin

[Cantor, Scott]

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

> I don't think you can do that with rapid Identity, the authentication API
> only takes into account the username and the source IP address.

I'll stop belaboring it, just seems hard to believe.

>    So I should be able to create the cookie store at the beginning of the
>flow, persist it in the authentication context, and then have the http
> client use it for each request.

Yes, the per-call state should all be in the HttpClientContext and/or our context tree.

>    If I understand correctly, the pieces in play would be defining the 
>    security parameters:

Yes, the parameter construction and those boilerplate calls to set it up with the right attributes and then check the results are required to enforce TLS requirements.

>    Yah, I meant a subcontext for the rapid authentication. I'm not quite 
>    clear though, is that primarily intended for persisting things that get 
>    passed out of the flow for other components to have available, or is it 
>    also the best place to persist whatever other random internal state is 
>    necessary within the flow itself for controlling execution between steps?

It's used for both because it's more portable than relying on WebFlow APIs for things like flow scope. We put things into flow or conversation scope to make it easier to access them in flow definition files in expressions.

The whole reason you can't cluster the servers to avoid stickiness during conversations is that we allow you to put anything in the context tree, and don't require it be serializable in a particular way.

-- Scott