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(a)redhat.com&gt; To: keycloak-user(a)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 Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

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. 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. Regards. Pedro Igor ----- Original Message ----- From: "Raghu Prabhala" <prabhalar(a)yahoo.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-user(a)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(a)redhat.com&gt; To: Bill Burke <bburke(a)redhat.com&gt; Cc: keycloak-user(a)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(a)redhat.com&gt; To: keycloak-user(a)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 Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user