[keycloak-user] UMA Profile for OAuth 2

Pedro Igor Silva psilva at redhat.com
Fri Sep 11 09:05:17 EDT 2015


Hey Raghu, nice to hear you too.

What you described is pretty much related with UMA, specially #2 and #3. There you have a specific token type, called RPT (Requesting Party Token), that contains the authorization data obtained from the AS when the client asks for authorization (on behalf of a requesting party) for a given resource and its scopes. Once the client obtains this token it can use it as a bearer token to access a resource on the RS. Here the RS is responsible to act as a PEP (Policy Enforcement Point) in order to introspect the RPT and decide whether the user is granted or not with enough permissions for a given resource.

There is also a whole dance to obtain this RPT (and also how you register these protected resources), which introduces additional steps before accessing a resource on a RS.

>From the specs, and also from references on the web, most UMA examples and scenarios are user-centric. In other words, where the user wants to share its own resources with others. Where these resources can be located in a single or different RSs.

What you described is what I meant about NPE use cases. Where we don't actually manage user-specific resources and their policies, but protect the resources for a specific client/application that is acting as a RS. For instance, protecting a RESTFul API. I'm still evaluating how UMA can be used without too much overhead in this case.

>From a policy perspective, UMA does not define how they are defined or managed. It is up to the implementation to decide what to do or use. In our case, we are evaluating Drools to defines policies and evaluate them. We are also considering XACML, but not for now ...

Regards.
Pedro Igor

----- Original Message -----
From: "Raghu Prabhala" <prabhalar at yahoo.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
Cc: keycloak-user at lists.jboss.org
Sent: Wednesday, September 9, 2015 11:50:36 PM
Subject: Re: [keycloak-user] UMA Profile for OAuth 2

Hi Pedro - Nice to hear from you after a long time. Whatever you are planning to implement for an organization is perhaps what we are looking for a resource application within an organization. There are two different scenarios we are trying to handle which may be different from what this spec is about but we are trying to tie everything together.  

1) A Client application will register with the Auth Server a list of "scopes" or permissions to access certain resource applications. But it doesn't mean that it will be able to gain access to all those resource apps (see the second point)
2) Each of the resource applications will register its own policy (a policy engine will need to be built to evaluate the requests and provide a decision) on what a client application can/cannot access - for example, a client application with client_id "client1" can only have read only access to resource app1 or even a certain part of the app.
3) When the client app uses the client credentials grant to obtain an access token to access resource application, the auth server will check both the policies and then provide the access token.
I haven't yet gone through the spec - so not clear whether it addresses the above but just wanted to share our thoughts with you.

Thanks,Raghu      From: Pedro Igor Silva <psilva at redhat.com>
 To: Bill Burke <bburke at redhat.com> 
Cc: keycloak-user at lists.jboss.org 
 Sent: Wednesday, September 9, 2015 10:44 AM
 Subject: Re: [keycloak-user] UMA Profile for OAuth 2
   

Hey Raghu,

    Fell free to share your requirements around authz and UMA. 

    We're considering two use cases and scenarios where the subject of a transaction can be an individual or a NPE (Non-person entity).    

    Right now, I'm focusing on NPE use cases, where an organization is both the resource owner and the authorizing party, acting on its own behalf, protecting its own resources. Which, IMO, helps to address most of the authz requirements for those applications that need to protect their own resources.

Regards.
Pedro Igor
    

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-user at lists.jboss.org
Sent: Wednesday, September 9, 2015 9:14:12 AM
Subject: Re: [keycloak-user] UMA Profile for OAuth 2

Pedro is working on a permission service on top of UMA, but it will be a 
separate service and/or an optional addon to keycloak.

On 9/9/2015 7:11 AM, Raghu Prabhala wrote:
> Bill/Stian,
>
> Do you have any plans to support the UMA profile for OAuth 2 in the near
> future?
>
> http://tools.ietf.org/html/draft-hardjono-oauth-umacore-13
>
> Thanks,
> Raghu
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


_______________________________________________
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




More information about the keycloak-user mailing list