I will do:
boolean authorized = realm.hasRole(user, role) && realm.hasScope(client,
role);
On 5/23/2014 11:00 AM, Stian Thorgersen wrote:
What about clients? You're then giving additional permissions to
a client that the user hasn't granted.
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 23 May, 2014 3:51:31 PM
> Subject: Re: [keycloak-dev] FYI: can't use token to auth admin console
>
> Our user-agent might not be a browser.
>
> On 5/23/2014 10:48 AM, Stian Thorgersen wrote:
>> Why not just do a window.reload(), which will redirect to login screen and
>> get a new token with the new roles?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Friday, 23 May, 2014 3:46:08 PM
>>> Subject: [keycloak-dev] FYI: can't use token to auth admin console
>>>
>>> Too much kid stuff lately! Sorry I haven't been productive past 2
>>> days...But...
>>>
>>> FYI: We can't use role mapping information in access token to authorize
>>> admin console access. This is because users may be creating new realms
>>> which will update their role mappings on the fly with the new admin
>>> roles created for that new realm.
>>>
>>> What will happen is that the client id will be extracted from token and
>>> authorization based on client scope and user role mappings will be done
>>> dynamically.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>>
http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
>