On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: It should support multi-valued and mapping to a array rather than a comma-separated list. On 1 February 2017 at 21:06, Stefan Schlesinger <sts(a)ono.at&gt; wrote: Hello, it looks like its currently not possible to use mod_auth_openidc with Keycloak for authorization of legacy applications. The current workaround described by mod_auth_openidc is to use OpenID Connect for authentication and use the apache ldap module for authorization, which is a rather ugly workaround IMHO. The problem currently is twofold: 1) One can use mod_auth_openidc to verify claims, but it doesn’t come with JSON path support[1], so matching the claims in realm_access.roles isn’t possible, only arrays in a flat JSON tree are supported[2]. 2) This wouldn’t cause any issues, as Keycloak comes with a User Realm Role mapper, which is able to map roles to a different key (in my example below the key is ‘roles’). { "jti": "01667279-a161-47ae-a093-b08643a1b7b5", "exp": 1485977685, … "realm_access": { "roles": [ “application_x", “application_y", "uma_authorization", ] }, "roles": “[application_x, application_y, uma_authorization]", } The problem with the mapper is that the value of roles, is served as a string instead of an array and mod_auth_openidc cannot handle this properly[3]. Btw. the same thing goes for the User Client Role mapper! Which looks like this: { "client_role": "[login]” } An issue for this has already been created: https://issues.jboss.org/browse/KEYCLOAK-4205 It would be so great to get this fixed in the next release!! Best, Stefan. [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOMMYeXt5Jc [2] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L85 [3] https://github.com/pingidentity/mod_auth_openidc/blob/master/src/authz.c#L67 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I'm afraid it's too late to include new things for 2.5. On 13 February 2017 at 12:16, Stefan Schlesinger <sts(a)ono.at&gt; wrote: > Hi Stian, > > is this something which could make it into one of the next 2.5 releases > (especially, > because 2.5 should be a version included in redhat, IIRC)? > > A working integration with mod_auth_openidc would be essential. > > Best, > > Stefan. > > > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > > It should support multi-valued and mapping to a array rather than a > comma-separated list. > > > > On 1 February 2017 at 21:06, Stefan Schlesinger <sts(a)ono.at&gt; wrote: > > Hello, > > > > it looks like its currently not possible to use mod_auth_openidc with > Keycloak for authorization of legacy applications. The current workaround > described by mod_auth_openidc is to use OpenID Connect for authentication > and use the apache ldap module for authorization, which is a rather ugly > workaround IMHO. > > > > The problem currently is twofold: > > > > 1) One can use mod_auth_openidc to verify claims, but it doesn’t come > with JSON path support[1], so matching the claims in realm_access.roles > isn’t possible, only arrays in a flat JSON tree are supported[2]. > > > > 2) This wouldn’t cause any issues, as Keycloak comes with a User Realm > Role mapper, which is able to map roles to a different key (in my example > below the key is ‘roles’). > > > > { > > "jti": "01667279-a161-47ae-a093-b08643a1b7b5", > > "exp": 1485977685, > > … > > "realm_access": { > > "roles": [ > > “application_x", > > “application_y", > > "uma_authorization", > > ] > > }, > > "roles": “[application_x, application_y, uma_authorization]", > > } > > > > The problem with the mapper is that the value of roles, is served as a > string instead of an array and mod_auth_openidc cannot handle this > properly[3]. > > > > Btw. the same thing goes for the User Client Role mapper! Which looks > like this: > > > > { > > "client_role": "[login]” > > } > > > > An issue for this has already been created: > https://issues.jboss.org/browse/KEYCLOAK-4205 > > > > It would be so great to get this fixed in the next release!! > > > > Best, > > > > Stefan. > > > > > > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/ > QOMMYeXt5Jc > > [2] https://github.com/pingidentity/mod_auth_openidc/blob/ > master/src/authz.c#L85 > > [3] https://github.com/pingidentity/mod_auth_openidc/blob/ > master/src/authz.c#L67 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

Actually, if you create the mapper and don't select anything for "Claim JSON Type" it maps it as an array. If you set the "Claim JSON Type" you don't have the option to select anything but String, which results in a single string rather than an array. On 13 February 2017 at 13:46, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > Actually on reviewing it again, I'd say this is a bug rather than a > enhancement request. What version are you using though? I just tried this > out and it's mapping it correctly for me: > > { > ..., > "test": [ > "create-realm", > "offline_access", > "admin", > "uma_authorization" > ] > } > > > On 13 February 2017 at 13:36, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> I'm afraid it's too late to include new things for 2.5. >> >> On 13 February 2017 at 12:16, Stefan Schlesinger <sts(a)ono.at&gt; wrote: >> >>> Hi Stian, >>> >>> is this something which could make it into one of the next 2.5 releases >>> (especially, >>> because 2.5 should be a version included in redhat, IIRC)? >>> >>> A working integration with mod_auth_openidc would be essential. >>> >>> Best, >>> >>> Stefan. >>> >>> > On 02 Feb 2017, at 07:10, Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> > >>> > It should support multi-valued and mapping to a array rather than a >>> comma-separated list. >>> > >>> > On 1 February 2017 at 21:06, Stefan Schlesinger <sts(a)ono.at&gt; wrote: >>> > Hello, >>> > >>> > it looks like its currently not possible to use mod_auth_openidc with >>> Keycloak for authorization of legacy applications. The current workaround >>> described by mod_auth_openidc is to use OpenID Connect for authentication >>> and use the apache ldap module for authorization, which is a rather ugly >>> workaround IMHO. >>> > >>> > The problem currently is twofold: >>> > >>> > 1) One can use mod_auth_openidc to verify claims, but it doesn’t come >>> with JSON path support[1], so matching the claims in realm_access.roles >>> isn’t possible, only arrays in a flat JSON tree are supported[2]. >>> > >>> > 2) This wouldn’t cause any issues, as Keycloak comes with a User >>> Realm Role mapper, which is able to map roles to a different key (in my >>> example below the key is ‘roles’). >>> > >>> > { >>> > "jti": "01667279-a161-47ae-a093-b08643a1b7b5", >>> > "exp": 1485977685, >>> > … >>> > "realm_access": { >>> > "roles": [ >>> > “application_x", >>> > “application_y", >>> > "uma_authorization", >>> > ] >>> > }, >>> > "roles": “[application_x, application_y, uma_authorization]", >>> > } >>> > >>> > The problem with the mapper is that the value of roles, is served as a >>> string instead of an array and mod_auth_openidc cannot handle this >>> properly[3]. >>> > >>> > Btw. the same thing goes for the User Client Role mapper! Which looks >>> like this: >>> > >>> > { >>> > "client_role": "[login]” >>> > } >>> > >>> > An issue for this has already been created: >>> https://issues.jboss.org/browse/KEYCLOAK-4205 >>> > >>> > It would be so great to get this fixed in the next release!! >>> > >>> > Best, >>> > >>> > Stefan. >>> > >>> > >>> > [1] https://groups.google.com/forum/#!topic/mod_auth_openidc/QOM >>> MYeXt5Jc >>> > [2] https://github.com/pingidentity/mod_auth_openidc/blob/master >>> /src/authz.c#L85 >>> > [3] https://github.com/pingidentity/mod_auth_openidc/blob/master >>> /src/authz.c#L67 >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev