OIDC authorization code flow, was SAML2 artifact and IdP clustering

[Janne Lauros]

Hi!

 Obviously I have not read the earlier mails before jumping to answer on extensions behalf (bad habit of mine) and I am not able to say anything about the "SAML 2.0 artifact use" but the mentioned facts still stand about extension. We store information only to these to caches, by default in memory. The nature of the caches is such that not sharing them you have less secure system otherwise functioning like a breeze. I hope this helps.

 BR Janne

----- Original Message -----
From: "Janne Lauros" <janne.lauros at csc.fi>
To: "dev" <dev at shibboleth.net>
Sent: Thursday, 14 February, 2019 16:54:27
Subject: Re: OIDC authorization code flow, was SAML2 artifact and IdP clustering

Hi Scott,

 We use replay cache (standard shibboleth cache) and revocation cache (cache to store information of revoked tokens). Those are the only parts of the extension that should have impact on clustering.

>Specifically, if one wants to use the standard OIDC authorization code
>flow with stateless clustering will it work?
>Is that how the OIDC authorization code flow is expected to work with
>stateless clustering?

 In short yes. If forgetting the above two caches you could say the implementation is totally stateless. Event the code flow.

 BR Janne


 

----- Original Message -----
From: "Scott Koranda" <skoranda at gmail.com>
To: "dev" <dev at shibboleth.net>
Sent: Thursday, 14 February, 2019 15:33:40
Subject: OIDC authorization code flow, was SAML2 artifact and IdP clustering

> > "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
-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net