[keycloak-user] Fw: Keycloak as stateless broker

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[keycloak-user] Fw: Keycloak as stateless broker

Leo C
 Hi,

We would like to use keycloak as an identity broker in such a way that the identity collected from the identity provider are not permanently stored, so to avoid a build-up of identities stored on the broker.

Ideally, we would like:


  *    Keycloak, as identity broker to accept SAML assertion from one of several identity providers
  *    To use (custom) authentication flows to normalise or transform some of the attributes to create a new UserModel and consequentially a new SAML response back to the service provider
  *    To not bring the UserModel (or any other personal details to rest in the database), though we would accept storing just the unique ID of the user if we could avoid storing other attributes, whilst still propagating them back to the service provider
  *    Ideally to make authorisation decisions based on groups or roles during the process – and stopping the authentication if those fail

Any ideas on the best way to proceed would be most appreciated.

Leo

(p.s. this email was originally sent to keycloak-dev distort by mistake. apologies)

_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user
Reply | Threaded
Open this post in threaded view
|

Re: [keycloak-user] Fw: Keycloak as stateless broker

Marek Posolda
On 19/05/17 13:27, Leo C wrote:

>   Hi,
>
> We would like to use keycloak as an identity broker in such a way that the identity collected from the identity provider are not permanently stored, so to avoid a build-up of identities stored on the broker.
>
> Ideally, we would like:
>
>
>    *    Keycloak, as identity broker to accept SAML assertion from one of several identity providers
>    *    To use (custom) authentication flows to normalise or transform some of the attributes to create a new UserModel and consequentially a new SAML response back to the service provider
>    *    To not bring the UserModel (or any other personal details to rest in the database), though we would accept storing just the unique ID of the user if we could avoid storing other attributes, whilst still propagating them back to the service provider
>    *    Ideally to make authorisation decisions based on groups or roles during the process – and stopping the authentication if those fail
There is already "first broker login" flow . See docs for more details.

Maybe the only you need is to modify the default flow and replace
IdpCreateUserIfUniqueAuthenticator with some else, which will just
create userModel to the memory (infinispan) but not to DB. This should
be somehow possible, maybe see also docs for User Storage for more details.

AFAIK we plan to support this option OOTB, but didn't yet implemented
it. Also we have broker mapper, where you can choose what attributes
from the SAML assertion should be added to the temporary user and hence
will be sent in SAML Assertion to the SP.

Marek

>
> Any ideas on the best way to proceed would be most appreciated.
>
> Leo
>
> (p.s. this email was originally sent to keycloak-dev distort by mistake. apologies)
>
> _______________________________________________
> keycloak-user mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/keycloak-user


_______________________________________________
keycloak-user mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/keycloak-user