[keycloak-dev] Role mapping capabilites in SAML adapter

[Hynek Mlnarik]

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 at 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/bd784f38fe2dd027b076d03f90a8f4bc8856a61f
> [2]
>
> https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/authentication/ClientCredentialsProvider.java
>
> Cheers!
>
> --
>
> Stefan Guilhen
>
> Principal Software Engineer
>
> Red Hat <https://www.redhat.com/>
>
> sguilhen at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>