[keycloak-user] Using Keycloak with Apache and mod_auth_oidc

[Thomas Darimont]

Hello,

I just gave this a try but couldn't find a way to propagate the roles
assigned to a user via a custom mapper.
What I could do was to add a "fixed role" for the client as a custom client
mapper as a "Hardcoded claim".

Mapper Configuration:

Name: custom_client_role
Mapper Type:  Hard coded claim
Token Claim Name: client_role
Claim value: user
Claim JSON Type: String
Add to ID token: ON (Note that this seems to be required for mod_auth_oidc
to include the claim in the headers by default)
Add to access token: ON

Cheers,
Thomas

2016-06-03 7:48 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Don't think there's a built-in option to add roles as a top-level
> attribute. You can create a JIRA for it. In the mean time you can also
> create your own custom mapper.
>
> On 3 June 2016 at 01:20, Anthony Fryer <anthony.fryer at gmail.com> wrote:
>
>> Just need to keep in mind if you want to use mod_auth_oidc to secure urls
>> using keycloak roles, there can be issues.  Is it possible to somehow map
>> keycloak roles to a top level attribute in the access token as a work
>> around?
>>
>> >>>>
>>
>> No, it is not possible to use json path syntax,  patches would be
>> welcome...
>>
>> Expression can be of limited complexity today: 1-level deep arrays are
>>  supported as are regular expressions. So if you would be able to instruct
>> your OP to send the roles in a top-level attribute called
>> "realm_access.roles", then what you currently have configured would work.
>>
>> Hans.
>>
>> On Tue, May 24, 2016 at 3:50 PM, <anthony.fryer at gmail.com> wrote:
>>
>>> I am using keycloak and have assigned some global roles (TOUPPER and
>>> REVERSE) to a user.  The decoded access token looks like this...
>>>
>>>         {
>>>   "jti" : "0a0541f2-9b74-4a41-b862-a20a3cbc2bcb",
>>>   "exp" : 1464097823,
>>>   "nbf" : 0,
>>>   "iat" : 1464097523,
>>>   "iss" : "https://my.keycloak.com/auth/realms/T
>>> <https://keycloak.cyberavenue.com.au/auth/realms/Glomex>enantA",
>>>   "aud" : "test-client",
>>>   "sub" : "20974f13-8272-4cd5-a172-5c8de4cdc782",
>>>   "typ" : "Bearer",
>>>   "azp" : "test-client",
>>>   "nonce" : "C_D0xDSCytoFaopJoYZu36BJcb6eMR2Xeg8VGP2nxeQ",
>>>   "session_state" : "b625d171-e01d-462c-9d01-d159b9b75635",
>>>   "name" : "",
>>>   "preferred_username" : "anthony",
>>>   "client_session" : "80b0ac34-5ee8-41f2-97da-649cf1abbd81",
>>>   "allowed-origins" : [ ],
>>>   "realm_access" : {
>>>     "roles" : [ "TOUPPER", "REVERSE" ]
>>>   },
>>>   "resource_access" : { },
>>>   "groups" : [ "tenantA/brandA", "tenantA" ]
>>> }
>>>
>>>
>>> I'm now trying to configure mod_auth_openidc authorization on some url
>>> paths based on the roles in the "realm_access"."roles" path of the token.
>>> I've tried this configuration...
>>>
>>>         <Location /glomex-mds-webapp/api/v1/secure/demo/toupper>
>>>                 AuthType openid-connect
>>>                 #Require valid-user
>>>                 Require claim realm_access.roles:TOUPPER
>>>         </Location>
>>>
>>> This doesn't seem to work though.  Is it possible to use json path
>>> syntax for claim authorization?
>>
>>
>> On Fri, Jun 3, 2016 at 7:30 AM, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello group,
>>>
>>> Just wanted to let you know that I build a small example [0] that
>>> demonstrates the usage of Keycloak with mod_auth_oidc [1]
>>> with Docker + Apache + PHP.
>>>
>>> Works like a charm :)
>>>
>>> Cheers,
>>> Thomas
>>>
>>> [0] https://github.com/thomasdarimont/keycloak_mod_auth_oidc_example
>>> [1] https://github.com/pingidentity/mod_auth_openidc
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160603/ad61cda8/attachment.html