Hi Stefan, thanks for the proposals. The first option fits only simple use cases. Let say there is an external identity provider but roles should be obtained from LDAP in internal network. I don't think Keycloak should provide default implementation other than the properties file, yet it should support extending the way to obtain the mapping so that the deployer can provide their e.g. own LDAP lookup code. The third option - Elytron - would be nice but as you say it is not easily portable to other containers. This leaves the second option as the best choice IMO. There would be no or negligible performance hit if the mapper was looked up and instantiated upon deployment. --Hynek On Thu, Jul 11, 2019 at 5:54 AM Stefan Guilhen <sguilhen(a)redhat.com&gt; wrote: > Hi all, > > I'm working on KEYCLOAK-7264 to add support for role mapping in the SAML > adapter and I wanted to discuss some of the options we have to do > implement > this. > > 1- My first take[1] was to enhance keycloak-saml.xml to allow for the > specification of the role mappings. We already have configuration for the > attributes of the assertion that contain roles, so it seemed natural to me > to add the ability to map the extracted roles into roles that exist in the > JEE container there. Implementation was straightforward, only piece > missing > is applying the same changes to the SAML subsystem that has to mirror the > configuration found in keycloak-saml.xml. This solution is portable across > containers as keycloak-saml.xml is common to all adapters. > 2- We could introduce a small SPI to map roles, similar to what we have for > the ClientCredentialsProvider [2], with a default implementation that, for > example, reads the mappings from a properties file. This allows for > different implementations of a role mapper but introduces another SPI and > I > believe it can be a bit overkill - if all that is required is a way to > perform some simple mapping I don't see the value of making this > extensible > via an SPI. > > 3- Use the mapping capabilities from Elytron. In WildFly, Elytron has some > built in mappers that could probably be reused but this option is not > portable across containers. It would work for WildFly or EAP but not for > the rest (at least not OOTB and I don't see people wanting to setup > Elytron > for other containers just to be able to perform some simple mappings). > Also, implementation of the subsystem becomes a little more complex with > the wiring required to get the Elytron mapper injected into the adapters. > > I'm still personally inclined towards the first approach but wanted to > know > your thoughts before proceeding with the subsystem changes. > > [1] > > https://github.com/sguilhen/keycloak/commit/bd784f38fe2dd027b076d03f90a8f... > [2] > > https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-co... > > Cheers! > > -- > > Stefan Guilhen > > Principal Software Engineer > > Red Hat <https://www.redhat.com/> > > sguilhen(a)redhat.com IM: sguilhen > @RedHat <https://twitter.com/redhat> Red Hat > <https://www.linkedin.com/company/red-hat> Red Hat > <https://www.facebook.com/RedHatInc> > <https://www.redhat.com/> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >