[keycloak-dev] Role mapping capabilites in SAML adapter

[Stefan Guilhen]

Hi Hynek,

Thanks for the feedback. I agree with the pros of defining an SPI, I was
just not sure if the demand for this mapping requires all that flexibility
- i.e. perhaps approach #1 was enough to address most use cases of mapping
SAML assertion roles to JEE container roles as there might be a mismatch
there. But reading the use case you've described, this is more than just
1:1 mapping of roles - as you've put it, one could use the SPI to add extra
roles that would in turn be retrieved from different places such as an
LDAP. I probably oversimplified the Jira.

I'll move forward with an SPI then - something like RoleMappingsProvider -
probably start with a simple method that takes the set of roles as
retrieved from the SAML assertion and returns a set of mapped (or enhanced)
roles. Using ClientCredentialsProvider as an example, we could also allow
config of the provider implementation in the keycloak.json (things such as
LDAP connection properties, for example) and pass this config in a call to
an init() method before doing any role mappings.

Cheers!

On Tue, Jul 16, 2019 at 3:46 AM Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> 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
>>
>

-- 

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/>