Hi All,
@Raghu, I think we already discussing this on GitHub :)
The understanding from both Guy Davis and Raghu are correct. Currently, KC provides
coarse-grained authz based on vanilla OAuth2 and roles/scopes within an access token.
There no fine-grained permissions where you can define permissions such as which actions
an identity is allowed to perform on a protected resource. Today, you need something on
the app side to handle that.
The whole idea behind Keycloak AuthZ is to leverage KC capabilities in order to
provide a Policy Administration Point (based on KC admin console), a Policy Decision Point
(based on a RESTFul API) and Policy Enforcement Points (something like KC adapters but for
authz). Given that, KC will be able to support different access control models (ABAC,
RBAC, GBAC, Risk or Context-based, etc) with a policy model that can be built around a
specific resource (or a set of resources) in order to decide whether an access is granted
or not.
Currently, that projects provide a minimal UMA implementation and UIs to manage
authorization policies, from where you can even simulate them to check for the outcome
before actually enforcing them into your application. There is also some initial
implementation of a JAX-RS based adapter that makes easier to integrate with the Keycloak
AuthZ server in order to enforce authorization for the protected resources. From an UMA
perspective, we are also planning to support more advanced use cases where an user can
authorize another to access his resource, but currently we are focusing on API security
use cases.
So, the list of things we are planning is pretty big and I hope to have some decisions
around this project after our meeting which will happen next month. More details can be
found here [1].
[1]
https://github.com/pedroigor/keycloak-authz
Regards.
Pedro Igor
----- Original Message -----
From: "Raghuram Prabhala" <prabhalar(a)yahoo.com>
To: "Bill Burke" <bburke(a)redhat.com>, keycloak-user(a)lists.jboss.org
Sent: Saturday, February 13, 2016 1:17:38 AM
Subject: Re: [keycloak-user] Course and Fine Grained Entitlements
Even our organization is looking for UMA modules (there are already a few vendors who
offer some version of UMA) and a couple of months back I tried out something that Pedro
put together which works with an old version of Keycloak. While I didn't explore the
features in detail, I found that to be very nicely integrated with keycloak and definitely
in the right direction. If anyone wants to look at it, here is the link. Please make sure
you follow all the build instructions (see
https://github.com/pedroigor/keycloak-authz/issues/31 also)
https://github.com/pedroigor/keycloak-authz
Raghu
From: Bill Burke <bburke(a)redhat.com>
To: keycloak-user(a)lists.jboss.org
Sent: Wednesday, February 3, 2016 2:03 PM
Subject: Re: [keycloak-user] Course and Fine Grained Entitlements
Pedro is working on that...He has some stuff. Hope he responds. Not going to be part of
Keycloak until 2.0 though. And yes, its around UMA.
On 2/3/2016 1:47 PM, Guy Davis wrote:
Hi Lars,
Good question. My organization is also asking similar questions about adopting Keycloak.
Let me give my understanding as a user, then Keycloak team can correct my
misunderstandings.
Basically, Keycloak offers coarse-grained authorizations ( realm-roles and client-app
roles ) assigned to users (or groups ). So I understand Keycloak will let you grant user
Bob the 'myapp-admin' role. However, it falls to the backend service or
application to then map that role to application-specific permissions. For example, role
'myapp-admins' can access /myapp/project1/admin page. This resource security can
be done (for Java apps) in declarative fashion using web.xml security constraints.
Alternatively, your application code could dynamically obtain the Keycloak user principal,
check their roles, and map into your app's permission scheme.
This understanding implies that your application is responsible for an admin UI to map
fine-grained permissions on your app's resources to Keycloak roles. If your app only
has 'coarse-grained" resources, then you can probably just use Keycloak roles,
with no need for a permission layer or the UI it entails.
Also, see this pre-amble about Permission Scopes . In future, it sounds like Keycloak team
is considering support for the UMA portion of the OAuth standard . This may help with
fine-grained permission management within Keycloak itself?
Hope this helps,
Guy
<sorry, original response was only to Lars, now to list as well>
On Tue, Feb 2, 2016 at 8:29 PM, Lars Noldan < lars.noldan(a)drillinginfo.com > wrote:
We're in the investigation stage on moving from a $BigExpensiveVendor solution toward
keycloak, and we're looking for a solution to help manage both Course and Fine grained
entitlements. Keycloak appears to be a fantastic authentication solution, but I'm
wondering what are you, the keycloak community using to handle Authorization?
Thanks!
_______________________________________________
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
--
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