1:46 a.m.
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> 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