OIDC authorization code flow, was SAML2 artifact and IdP clustering

[Scott Koranda]

> > "SAML 2.0 artifact use is not supported by default if more than one node is
> > deployed, but it is possible to make that feature work with additional
> > configuration (discussion TBD)."
> > 
> > Is there "additional configuration" that will enable SAML 2.0 artifact use that
> > does NOT require using a separate relational database or key store?
> 
> You need a dedicated path into each node under a unique name (and certificate, or at least a multi-name cert), and then you can register separate indexed endpoints into the metadata. Each node has a property we defined assigning it the index value to use, and that gets embedded into the artifact to direct the requests back to the right node.
> 
> Is that enough to go on or do you need a more complete write up?
> 
> I never documented it due to the obvious lack of demand.
> 
> -- Scott

I am purposely moving this to the DEV list. I apologize if that is not
correct, please let me know if it is not.

I understand from your response how stateless clustering can accommodate
the SAML2 artifact flow.

I am wondering how the new OIDC work done by our friends in Finland can
be used with stateless clustering?

Specifically, if one wants to use the standard OIDC authorization code
flow with stateless clustering will it work?

I suspect that the necessary details like the user's principal can be
embedded into the authorization code before it is encrypted and sent to
the browser. Then that encrypted code can be decrypted and parsed by the
receiving IdP node to determine the principal, look up attributes, and
send the identity token.

Is that how the OIDC authorization code flow is expected to work with
stateless clustering?

Thanks,

Scott K