[keycloak-user] Uma ticket

[Geoffrey Cleaves]

UMA tickets are sent by the resource server to the client when the access
token does not have the necessary permissions. The client uses the ticket
to enrich the access token with permission information, which can then be
sent back to the resource server in order to access the resource. UMA
tickets do not replace tokens.

In Keycloak, users (and clients) have roles. When using UMA protection, you
can use roles to determine what resources and scopes a user can access. For
example, if the client tries to POST to /bank_accounts with an access
token, your resource server could create a permission ticket requesting the
create scope for the bank_account resource. The resource server responds
with 401 and the permission ticker to the client. The client is smart
enough to see the permission ticket and in turn sends the ticket (and auth
token) to Keycloak. Keycloak can then look up the user's roles to determine
if the user has the create scope for bank_accounts. Keycloak responds with
an access token which includes the permissions, and with the new token the
client once again tries to POST to /bank_accounts. The resource server
confirms the permissions and creates a bank account.

You don't need to use roles to determine UMA permissions. You can use
groups, attributes, whatever you want.

You don't actually need to use UMA permissions for the scenario described
above. Access tokens usually have roles included in them. The resource
server could examine the roles in the token to determine whether she can
create a bank account or not.

See
https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter
and
https://www.keycloak.org/docs/latest/authorization_services/index.html#_enforcer_js_adapter
for javascript and UMA tips.


On Fri, 21 Dec 2018 at 16:09, BELMONTET Matthieu <m.belmontet at systel-sa.com>
wrote:

> Good morning every body
>
> With the 4.x.x of keycloak we can ask for uma ticket with a specific
> permission for an user.
>
> I'm really interested by this feature to set up a role access to my
> application.
> I found the way to test it with the REST calling.
> I wonder if you work on the login page to implement this feature. "After
> login form, the page can propose to select a role in  the list  and then
> return generate the uma-ticket"?
> If it isn't planned. Should I work only with my uma-ticket which replace
> the authentication token or I should keep the authentication token too and
> send both in the header of my http requests?
> If I keep both, should I refresh both?
>
> How to access with keycloak -angular library to the uma ticket API?
>
>
> Thank you
>
> BELMONTET Matthieu
> ______________________________________
> Systel
> Pôle concevoir
> *: m.belmontet at systel-sa.com<mailto:m.belmontet at systel-sa.com>
> ______________________________________
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>


-- 

Regards,
Geoffrey Cleaves