8:13 p.m.
Hey guys, just catching up on the discussion. Let me share some
lessons learned from the Last four years on OpenStack Keystone working
on a very similar problem.
Keystone started off with three concepts: users, (global) roles and
tenants. A user was either an admin (based on a role) or assigned to a
tenant.
Tenants were groups of resources not managed by Keystone; Virtual
machines, disk images, and the like. All access control was managed by
the user having a token scoped to the project.
Admin was a global role...but at some point, someone decided to make it
scoped to a tenant. And things go weird. But it made sense: within a
proejct, some resources were more sensitive than others, and needed an
increased level of security. But since all of the access control policy
was written with global roles, things were actually just kind of
broken. It lead to one of the oldest bugs in Keystone, and it is still
assigned to me. I think we will have it licked this round...but that is
jumping ahead.
Keystone was written with a plugable backend approach. THe default was
Key Value stores (memcache was heavily used) but SQL was very dominant.
However, we realized that, for users, we needed to be able to pull them
out of LDAP, as most companies have large, embedded user databases, and
they want to user them, not copy them. So, projects in Openstack mapped
to groups in LDAP, and users had assignments to groups.
It was an uncomfortable fit. Tenants really were OpenStack
abstractions, and with them coming from LDAP...which was almost always
read-only, they were not editable by OpenStack resources. This was a
restriction that we dealt with for a while.
A couple new abstractions found their way into Keystone: groups (of
users) and domains. Domains were groupings for both users and tenants.
And this has continued to haunt us, because it confused two things. The
above situation with LDAP showed that the users needed to be separate
from the tenants.
Oh, and we also changed the name from tenants to projects to keep
consistent with the rest of OpenStack...want to piss off your users?
Change a key term out from underneath them...
It became clear the we needed to manage users and projects in different
ways. Users were read only from LDAP, projects were writable from
OpenStack. We split the backends along these lines: Identity manages
users, groups, and user-to-group assignments. This was due to the4
expectation that the group information from LDAP was going to be
required for managing users, which has proven to be of questionable
worth. The assignment backend held projects, roles, and role
assignments. Domains were in there as well, but it was an awkward fit,
as domains really spanned both Identity and Assignment.
We also changed how the user to projects mapping was handled: we use
role assignments for everything. Domain *owned* users, in that they
were records under the domain object, but a user got no permissions due
to being managed by a specific domain; only via role assignments.
Things really got funky when we fully integrated Federation in to
Keystone. Now, we had two abstractions for managing users: Domains and
Identity Providers. Instead of making a hard relationship between the
two...we sort of let them float.
The most hackish part is the Mapping. This is what takes the values from
the federation assertion (SAML for the most part) and maps it to
Keystone Identity objects (users and groups). While we should limit
what IdP can map to what domain, we don't. What this means is the
managing the mapping must be done by an admin, and that is a
cetrnalization I had hoped to avoid.
What do end users really need? They need a reusable set of role
assignments that span mulitple (micro)services. We are almost there,
and a few more iterations and we can get there. Keystone handles only
the core OpenStack services, but it would be much more useful if we
could open it up to the cloud in general, and make it so people could
use the Federation mapping defined in there to provide Access control to
applications running in the cloud.
Lessons learned:
Scope roles to your target abstraction from the beginning. Call this
Scoped RBAC, as opposed to what NIST does. NIST is implicitly scoped,
make KeyCLoack be explicit. Call it project, tenant, target,
application, I don't care; but a user should have a role on
*something*, otherwise you end up with namespacing inside the role
names, and a second level of mapping required.
Provide rules that allow one to explicitly assign a single role, and the
target user gets that explicit role and multiple implicit roles. The
end product is actually as set, not a tree, so just watch out for
cycles. It does not have to be a strict hierarchy, so long as it is a
Directed Acyclic Graph, you are safe.
Namespacing of roles is a client organization thing; it does not need to
end up in the roles shipped to the end application, so long as you have
a global definition of what roles mean what. Regardless, the namespace
needs to disappear when sending the assertion, or the remote side can;t
use it. So, knowing "who" you are getting an assertion for is
essential. Two different Wordpress installs mean two different role
assignments: admin on one, editor on the other.
You don't own the user database. Assume it is going to be read only.
Provide a local means to manage groups of users separate from, but on
top of, the groups that come from the federated source of Identity.
OK, that is a lot of a brain dump from someone you all don't even know.
PLease ask me questions about the details.
I'm pretty impressed with what I've seen of KeyCloak thus far. Looking
forward to getting to know it better.
9:50 p.m.
We should have a Google Hangout or BlueJeans sometime:
before I get deeper, you'll have to explain more on what you mean that
you wanted to avoid centralization of mapping SAML assertions. I didn't
get that part...
I think this is related to a lot of what you wrote, but resource
permissions are going to be a separate, but integrated service to
roles/users/groups. Pedro is working on a permission service that
allows you to have complex permission models. There's some nice
protocols out there that help manage this.
Most Java EE apps, simple permission stuff is handled by the
applications themselves. The security layer propagates identity and
user/role mappings and the application decides which roles have
permission to access which resource. So, Keycloak core can focus on
provide user/group/role/attribute authentication and information. The
service Pedro is working on will offer an optional, complimentary way to
centrally manage permissions if you want to. My on personal opinion is
that most apps will want to manage resource permissions in their own
special app-specific way and Pedro's stuff will be most useful as a
backend-service.
As for our architecture, we have a common security domain model that all
our core component work with. This is a pluggable abstraction that is
designed to sit on a pluggable datastore. We currently have SQL and
Mongo mappings sitting on top of our own datamodel. We have a
distributed, clustered cache sitting on top of our datamodel
(Infinispan). It uses an invalidation model to keep synching message
size minimal and to avoid transmiting sensitive data.
For federation of external identity stores (i.e. LDAP) we offer a hybrid
approach. The idea is that we want Keycloaok to have a set of features
that a user can leverage irregardless of whether the underlying external
store can handle it or not. This means that Keylocak might locally
store additional security metadata that is not available in the LDAP
store. The SPI is a bit complex right now, but we're hoping to fix
that. It also requires some minimal import of data for each user
(username/email). We want to code that requirement out though in the
future.
On 11/22/2015 9:13 PM, Adam Young wrote:
Hey guys, just catching up on the discussion. Let me share some
lessons learned from the Last four years on OpenStack Keystone working
on a very similar problem.
Keystone started off with three concepts: users, (global) roles and
tenants. A user was either an admin (based on a role) or assigned to a
tenant.
Tenants were groups of resources not managed by Keystone; Virtual
machines, disk images, and the like. All access control was managed by
the user having a token scoped to the project.
Admin was a global role...but at some point, someone decided to make it
scoped to a tenant. And things go weird. But it made sense: within a
proejct, some resources were more sensitive than others, and needed an
increased level of security. But since all of the access control policy
was written with global roles, things were actually just kind of
broken. It lead to one of the oldest bugs in Keystone, and it is still
assigned to me. I think we will have it licked this round...but that is
jumping ahead.
Keystone was written with a plugable backend approach. THe default was
Key Value stores (memcache was heavily used) but SQL was very dominant.
However, we realized that, for users, we needed to be able to pull them
out of LDAP, as most companies have large, embedded user databases, and
they want to user them, not copy them. So, projects in Openstack mapped
to groups in LDAP, and users had assignments to groups.
It was an uncomfortable fit. Tenants really were OpenStack
abstractions, and with them coming from LDAP...which was almost always
read-only, they were not editable by OpenStack resources. This was a
restriction that we dealt with for a while.
A couple new abstractions found their way into Keystone: groups (of
users) and domains. Domains were groupings for both users and tenants.
And this has continued to haunt us, because it confused two things. The
above situation with LDAP showed that the users needed to be separate
from the tenants.
Oh, and we also changed the name from tenants to projects to keep
consistent with the rest of OpenStack...want to piss off your users?
Change a key term out from underneath them...
It became clear the we needed to manage users and projects in different
ways. Users were read only from LDAP, projects were writable from
OpenStack. We split the backends along these lines: Identity manages
users, groups, and user-to-group assignments. This was due to the4
expectation that the group information from LDAP was going to be
required for managing users, which has proven to be of questionable
worth. The assignment backend held projects, roles, and role
assignments. Domains were in there as well, but it was an awkward fit,
as domains really spanned both Identity and Assignment.
We also changed how the user to projects mapping was handled: we use
role assignments for everything. Domain *owned* users, in that they
were records under the domain object, but a user got no permissions due
to being managed by a specific domain; only via role assignments.
Things really got funky when we fully integrated Federation in to
Keystone. Now, we had two abstractions for managing users: Domains and
Identity Providers. Instead of making a hard relationship between the
two...we sort of let them float.
The most hackish part is the Mapping. This is what takes the values from
the federation assertion (SAML for the most part) and maps it to
Keystone Identity objects (users and groups). While we should limit
what IdP can map to what domain, we don't. What this means is the
managing the mapping must be done by an admin, and that is a
cetrnalization I had hoped to avoid.
What do end users really need? They need a reusable set of role
assignments that span mulitple (micro)services. We are almost there,
and a few more iterations and we can get there. Keystone handles only
the core OpenStack services, but it would be much more useful if we
could open it up to the cloud in general, and make it so people could
use the Federation mapping defined in there to provide Access control to
applications running in the cloud.
Lessons learned:
Scope roles to your target abstraction from the beginning. Call this
Scoped RBAC, as opposed to what NIST does. NIST is implicitly scoped,
make KeyCLoack be explicit. Call it project, tenant, target,
application, I don't care; but a user should have a role on
*something*, otherwise you end up with namespacing inside the role
names, and a second level of mapping required.
Provide rules that allow one to explicitly assign a single role, and the
target user gets that explicit role and multiple implicit roles. The
end product is actually as set, not a tree, so just watch out for
cycles. It does not have to be a strict hierarchy, so long as it is a
Directed Acyclic Graph, you are safe.
Namespacing of roles is a client organization thing; it does not need to
end up in the roles shipped to the end application, so long as you have
a global definition of what roles mean what. Regardless, the namespace
needs to disappear when sending the assertion, or the remote side can;t
use it. So, knowing "who" you are getting an assertion for is
essential. Two different Wordpress installs mean two different role
assignments: admin on one, editor on the other.
You don't own the user database. Assume it is going to be read only.
Provide a local means to manage groups of users separate from, but on
top of, the groups that come from the federated source of Identity.
OK, that is a lot of a brain dump from someone you all don't even know.
PLease ask me questions about the details.
I'm pretty impressed with what I've seen of KeyCloak thus far. Looking
forward to getting to know it better.
_______________________________________________
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
8:22 a.m.
On 11/22/2015 10:50 PM, Bill Burke wrote:
Most Java EE apps, simple permission stuff is handled by the
applications themselves. The security layer propagates identity and
user/role mappings and the application decides which roles have
permission to access which resource. So, Keycloak core can focus on
provide user/group/role/attribute authentication and information. The
service Pedro is working on will offer an optional, complimentary way to
centrally manage permissions if you want to. My on personal opinion is
that most apps will want to manage resource permissions in their own
special app-specific way and Pedro's stuff will be most useful as a
backend-service.
So the analogue in Keystone is the Policy stuff. Again, Keystone
has
had to weather a storm;
Access Control permissions in OpenStack are done at the Python API (not
URL) level. The code calls out to the policy API to check that the
context of the call matches the attributes of the resource. Practically
speaking, this means two checks: does the role match, and does the
scope (project or user) match.
It would be easier for deployers if it was URL based. Instead, it is
deep in the code, and the reason being that often an application needs
to fetch an object from the database to check ownership before checking
scope (what project owns the resource). What we learned is that this
can and should actually be two checks. The role check can be done in a
non-application specific way, and performed in the middleware stack;
kinda like in the Tomcat Webserver prior to hitting the servlet itself,
but in a python WSGI way instead. This part could and should be
dynamically fetched from the Keystone server. Only the scope check
needs to be done in a resource specific way. There is support at the
EJB/Hibernate layer for this kind of access control, too, and that may
be a better place to focus on completely. I suspect it is this kind of
"Dynamic Policy" stuff that Pedro is working on. Do we have docs for
that? I'd love to compare notes.
I'm in the US, on East Coast time. THis is a short Week due to
Thanksgiving, but I'd love to have a video conference of some sort the
following week to sync up the lessons learned from both projects.
8:32 a.m.
Pedro is currently away on holiday. I believe he's back in two weeks. We
should have an early alpha ready for the authorization services shortly
after he's back. You can check out the code at
https://github.com/pedroigor/keycloak-authz, but AFAIK it's not quite ready
for consumption.
The aim of the alpha is to have something available for others to play with
and to obtain feedback. It's still very much open to be discussed.
Your feedback would be very welcome, but we should wait until Pedro is back
before we continue the discussion.
On 23 November 2015 at 15:22, Adam Young <ayoung(a)redhat.com> wrote:
On 11/22/2015 10:50 PM, Bill Burke wrote:
> Most Java EE apps, simple permission stuff is handled by the
> applications themselves. The security layer propagates identity and
> user/role mappings and the application decides which roles have
> permission to access which resource. So, Keycloak core can focus on
> provide user/group/role/attribute authentication and information. The
> service Pedro is working on will offer an optional, complimentary way to
> centrally manage permissions if you want to. My on personal opinion is
> that most apps will want to manage resource permissions in their own
> special app-specific way and Pedro's stuff will be most useful as a
> backend-service.
So the analogue in Keystone is the Policy stuff. Again, Keystone has
had to weather a storm;
Access Control permissions in OpenStack are done at the Python API (not
URL) level. The code calls out to the policy API to check that the
context of the call matches the attributes of the resource. Practically
speaking, this means two checks: does the role match, and does the
scope (project or user) match.
It would be easier for deployers if it was URL based. Instead, it is
deep in the code, and the reason being that often an application needs
to fetch an object from the database to check ownership before checking
scope (what project owns the resource). What we learned is that this
can and should actually be two checks. The role check can be done in a
non-application specific way, and performed in the middleware stack;
kinda like in the Tomcat Webserver prior to hitting the servlet itself,
but in a python WSGI way instead. This part could and should be
dynamically fetched from the Keystone server. Only the scope check
needs to be done in a resource specific way. There is support at the
EJB/Hibernate layer for this kind of access control, too, and that may
be a better place to focus on completely. I suspect it is this kind of
"Dynamic Policy" stuff that Pedro is working on. Do we have docs for
that? I'd love to compare notes.
I'm in the US, on East Coast time. THis is a short Week due to
Thanksgiving, but I'd love to have a video conference of some sort the
following week to sync up the lessons learned from both projects.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:40 a.m.
On 11/23/2015 9:22 AM, Adam Young wrote:
On 11/22/2015 10:50 PM, Bill Burke wrote:
> Most Java EE apps, simple permission stuff is handled by the
> applications themselves. The security layer propagates identity and
> user/role mappings and the application decides which roles have
> permission to access which resource. So, Keycloak core can focus on
> provide user/group/role/attribute authentication and information. The
> service Pedro is working on will offer an optional, complimentary way to
> centrally manage permissions if you want to. My on personal opinion is
> that most apps will want to manage resource permissions in their own
> special app-specific way and Pedro's stuff will be most useful as a
> backend-service.
So the analogue in Keystone is the Policy stuff. Again, Keystone has
had to weather a storm;
Access Control permissions in OpenStack are done at the Python API (not
URL) level. The code calls out to the policy API to check that the
context of the call matches the attributes of the resource. Practically
speaking, this means two checks: does the role match, and does the
scope (project or user) match.
We really should have a BJ session. Basic Java EE does permission via
URL. Pedro's stuff will be a lot more abstract. You would submit your
parameters (user, group, role, resource attributes, etc.) and get back
authorization permissions. All through the UMA protocol. URL is just
one type of resource in Pedro's stuff...Pedro should answer though.
Stian and I really only have a high level understanding of what he is doing.
It would be easier for deployers if it was URL based. Instead, it is
deep in the code, and the reason being that often an application needs
to fetch an object from the database to check ownership before checking
scope (what project owns the resource). What we learned is that this
can and should actually be two checks. The role check can be done in a
non-application specific way, and performed in the middleware stack;
We don't know shit about the Python stack. Personally I haven't touched
Python in 15 years. But anything Java based we have a good pulse on.
We've focused mostly on basic Java EE authorization. Most of our users
are interested in Keycloak out of the box, or customizing the federation
and/or authentication flows.
kinda like in the Tomcat Webserver prior to hitting the servlet
itself,
but in a python WSGI way instead. This part could and should be
dynamically fetched from the Keystone server. Only the scope check
needs to be done in a resource specific way. There is support at the
EJB/Hibernate layer for this kind of access control, too, and that may
be a better place to focus on completely. I suspect it is this kind of
"Dynamic Policy" stuff that Pedro is working on. Do we have docs for
that? I'd love to compare notes.
I'm in the US, on East Coast time. THis is a short Week due to
Thanksgiving, but I'd love to have a video conference of some sort the
following week to sync up the lessons learned from both projects.
Yes! Let's figure something out.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:43 a.m.
+1 Let's all have a hangout when Pedro returns :)
On 23 November 2015 at 15:40, Bill Burke <bburke(a)redhat.com> wrote:
On 11/23/2015 9:22 AM, Adam Young wrote:
> On 11/22/2015 10:50 PM, Bill Burke wrote:
>> Most Java EE apps, simple permission stuff is handled by the
>> applications themselves. The security layer propagates identity and
>> user/role mappings and the application decides which roles have
>> permission to access which resource. So, Keycloak core can focus on
>> provide user/group/role/attribute authentication and information. The
>> service Pedro is working on will offer an optional, complimentary way to
>> centrally manage permissions if you want to. My on personal opinion is
>> that most apps will want to manage resource permissions in their own
>> special app-specific way and Pedro's stuff will be most useful as a
>> backend-service.
> So the analogue in Keystone is the Policy stuff. Again, Keystone has
> had to weather a storm;
>
> Access Control permissions in OpenStack are done at the Python API (not
> URL) level. The code calls out to the policy API to check that the
> context of the call matches the attributes of the resource. Practically
> speaking, this means two checks: does the role match, and does the
> scope (project or user) match.
>
We really should have a BJ session. Basic Java EE does permission via
URL. Pedro's stuff will be a lot more abstract. You would submit your
parameters (user, group, role, resource attributes, etc.) and get back
authorization permissions. All through the UMA protocol. URL is just
one type of resource in Pedro's stuff...Pedro should answer though.
Stian and I really only have a high level understanding of what he is
doing.
>
> It would be easier for deployers if it was URL based. Instead, it is
> deep in the code, and the reason being that often an application needs
> to fetch an object from the database to check ownership before checking
> scope (what project owns the resource). What we learned is that this
> can and should actually be two checks. The role check can be done in a
> non-application specific way, and performed in the middleware stack;
We don't know shit about the Python stack. Personally I haven't touched
Python in 15 years. But anything Java based we have a good pulse on.
We've focused mostly on basic Java EE authorization. Most of our users
are interested in Keycloak out of the box, or customizing the federation
and/or authentication flows.
> kinda like in the Tomcat Webserver prior to hitting the servlet itself,
> but in a python WSGI way instead. This part could and should be
> dynamically fetched from the Keystone server. Only the scope check
> needs to be done in a resource specific way. There is support at the
> EJB/Hibernate layer for this kind of access control, too, and that may
> be a better place to focus on completely. I suspect it is this kind of
> "Dynamic Policy" stuff that Pedro is working on. Do we have docs for
> that? I'd love to compare notes.
>
> I'm in the US, on East Coast time. THis is a short Week due to
> Thanksgiving, but I'd love to have a video conference of some sort the
> following week to sync up the lessons learned from both projects.
Yes! Let's figure something out.
--
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
11:01 a.m.
On 11/23/2015 09:40 AM, Bill Burke wrote:
On 11/23/2015 9:22 AM, Adam Young wrote:
> On 11/22/2015 10:50 PM, Bill Burke wrote:
>> Most Java EE apps, simple permission stuff is handled by the
>> applications themselves. The security layer propagates identity and
>> user/role mappings and the application decides which roles have
>> permission to access which resource. So, Keycloak core can focus on
>> provide user/group/role/attribute authentication and information. The
>> service Pedro is working on will offer an optional, complimentary way to
>> centrally manage permissions if you want to. My on personal opinion is
>> that most apps will want to manage resource permissions in their own
>> special app-specific way and Pedro's stuff will be most useful as a
>> backend-service.
> So the analogue in Keystone is the Policy stuff. Again, Keystone has
> had to weather a storm;
>
> Access Control permissions in OpenStack are done at the Python API (not
> URL) level. The code calls out to the policy API to check that the
> context of the call matches the attributes of the resource. Practically
> speaking, this means two checks: does the role match, and does the
> scope (project or user) match.
>
We really should have a BJ session. Basic Java EE does permission via
URL. Pedro's stuff will be a lot more abstract. You would submit your
parameters (user, group, role, resource attributes, etc.) and get back
authorization permissions. All through the UMA protocol. URL is just
one type of resource in Pedro's stuff...Pedro should answer though.
Stian and I really only have a high level understanding of what he is doing.
> It would be easier for deployers if it was URL based. Instead, it is
> deep in the code, and the reason being that often an application needs
> to fetch an object from the database to check ownership before checking
> scope (what project owns the resource). What we learned is that this
> can and should actually be two checks. The role check can be done in a
> non-application specific way, and performed in the middleware stack;
We don't know shit about the Python stack. Personally I haven't touched
Python in 15 years. But anything Java based we have a good pulse on.
We've focused mostly on basic Java EE authorization. Most of our users
are interested in Keycloak out of the box, or customizing the federation
and/or authentication flows.
This is really not a Python issue, rather it is how OpenStack has
evolved. People forked off the main project and cargo-culted in the
Access control implementations: good, bad and Ugly.
But the lesson learned is that there are two layers: URL based and
underlying resource. You can't count on the URL layer to properly
protect access at the persistence layer. You saw this reflected in J2EE
way back with Servlet VS Entity-EJB protections, and the modern
evolution of them as well.
JEE/JPA seems to have a "Role" check as its basic level of control. What
we've seen is this is only half of what we need. THe role needs to be
assigned on some collective aspect of ownership in order for the pattern
to scale.
Lets say that we are managing virtual machines. There are three levels
of VMs: development, qe, production.
If you say that anyone withthe "VM_MANAGER" role can create a VM, they
will be able to create VMs for dev, qe, and production. This is not
what you want. Instead:
A Dev should be able to create a VM in Dev, view it in QE, not be to do
anything in production
A QE-Engineer should be able to create a VM in QE, view it in Dev, and
not do anything in production
Production Level VMs can only be managed by automated processes that are
kicked off based on a quorum (at least 2 votes) of QE engineers.
There are multiple Dev groups: AccountsReceivable, AccountsPayable,
GeneraLedger, Tax. Each can work within their own set of VMs only, but
all must have the same set of rules.
Within a development group, there are a handful of roles: developers,
DBa, Manager, QA (assigned over from the core QA org. These people can
do various things to the VMs inside their own projects, but nothing
inside the other dev groups.
You get the idea. The roles and access permissions need to be
scalable. It can't be one size fits all, and it can't be hardcoded.
The general mechanism is a tuple:
role, actor, target.
Role is a string that describes what the user can do.
Actor is User or Group of users
Target is the container for the resources. In OpenStack, we have two:
Projects and Domains, but this is a mistake, as we could have used
Project for both.
If you were managing Wordpress deployments, the roles would be:
Administrator
Editor
Subscriber
Author
Contributor
And the Target would be the actual instance: and editor on one may be
an author on another.
The real power of this model comes in delegation. You want to know who
assigned what role to whom.
In OpenStack, we are working toward a unified delegation model, that
links short term delegations (Trusts and OAuth) with Role Assignments.
This is up for review here:
https://review.openstack.org/#/c/189816/15
There is a real need to be able to assign identities to non-human
entities, and to be able to delegate the appropriate permissions to
them. In FreeIPA, we are making more and more use of the Service
principals to do that.
> kinda like in the Tomcat Webserver prior to hitting the servlet itself,
> but in a python WSGI way instead. This part could and should be
> dynamically fetched from the Keystone server. Only the scope check
> needs to be done in a resource specific way. There is support at the
> EJB/Hibernate layer for this kind of access control, too, and that may
> be a better place to focus on completely. I suspect it is this kind of
> "Dynamic Policy" stuff that Pedro is working on. Do we have docs for
> that? I'd love to compare notes.
>
> I'm in the US, on East Coast time. THis is a short Week due to
> Thanksgiving, but I'd love to have a video conference of some sort the
> following week to sync up the lessons learned from both projects.
Yes! Let's figure something out.
11:10 a.m.
I only speed read your response (I'll review again after thanksgiving),
but I believe Hawkular has similar role/permission requirements. As I
said before, Keycloak is currently weak on authorization. A User has
Group Membership and Role mappings and attributes. That's it right now.
How the application applies that security metadata is up to the app.
Excited to talk to you though when Pedro gets back from vacation.
On 11/25/2015 12:01 PM, Adam Young wrote:
On 11/23/2015 09:40 AM, Bill Burke wrote:
>
> On 11/23/2015 9:22 AM, Adam Young wrote:
>> On 11/22/2015 10:50 PM, Bill Burke wrote:
>>> Most Java EE apps, simple permission stuff is handled by the
>>> applications themselves. The security layer propagates identity and
>>> user/role mappings and the application decides which roles have
>>> permission to access which resource. So, Keycloak core can focus on
>>> provide user/group/role/attribute authentication and information. The
>>> service Pedro is working on will offer an optional, complimentary way to
>>> centrally manage permissions if you want to. My on personal opinion is
>>> that most apps will want to manage resource permissions in their own
>>> special app-specific way and Pedro's stuff will be most useful as a
>>> backend-service.
>> So the analogue in Keystone is the Policy stuff. Again, Keystone has
>> had to weather a storm;
>>
>> Access Control permissions in OpenStack are done at the Python API (not
>> URL) level. The code calls out to the policy API to check that the
>> context of the call matches the attributes of the resource. Practically
>> speaking, this means two checks: does the role match, and does the
>> scope (project or user) match.
>>
> We really should have a BJ session. Basic Java EE does permission via
> URL. Pedro's stuff will be a lot more abstract. You would submit your
> parameters (user, group, role, resource attributes, etc.) and get back
> authorization permissions. All through the UMA protocol. URL is just
> one type of resource in Pedro's stuff...Pedro should answer though.
> Stian and I really only have a high level understanding of what he is doing.
>
>> It would be easier for deployers if it was URL based. Instead, it is
>> deep in the code, and the reason being that often an application needs
>> to fetch an object from the database to check ownership before checking
>> scope (what project owns the resource). What we learned is that this
>> can and should actually be two checks. The role check can be done in a
>> non-application specific way, and performed in the middleware stack;
> We don't know shit about the Python stack. Personally I haven't touched
> Python in 15 years. But anything Java based we have a good pulse on.
> We've focused mostly on basic Java EE authorization. Most of our users
> are interested in Keycloak out of the box, or customizing the federation
> and/or authentication flows.
This is really not a Python issue, rather it is how OpenStack has
evolved. People forked off the main project and cargo-culted in the
Access control implementations: good, bad and Ugly.
But the lesson learned is that there are two layers: URL based and
underlying resource. You can't count on the URL layer to properly
protect access at the persistence layer. You saw this reflected in J2EE
way back with Servlet VS Entity-EJB protections, and the modern
evolution of them as well.
JEE/JPA seems to have a "Role" check as its basic level of control. What
we've seen is this is only half of what we need. THe role needs to be
assigned on some collective aspect of ownership in order for the pattern
to scale.
Lets say that we are managing virtual machines. There are three levels
of VMs: development, qe, production.
If you say that anyone withthe "VM_MANAGER" role can create a VM, they
will be able to create VMs for dev, qe, and production. This is not
what you want. Instead:
A Dev should be able to create a VM in Dev, view it in QE, not be to do
anything in production
A QE-Engineer should be able to create a VM in QE, view it in Dev, and
not do anything in production
Production Level VMs can only be managed by automated processes that are
kicked off based on a quorum (at least 2 votes) of QE engineers.
There are multiple Dev groups: AccountsReceivable, AccountsPayable,
GeneraLedger, Tax. Each can work within their own set of VMs only, but
all must have the same set of rules.
Within a development group, there are a handful of roles: developers,
DBa, Manager, QA (assigned over from the core QA org. These people can
do various things to the VMs inside their own projects, but nothing
inside the other dev groups.
You get the idea. The roles and access permissions need to be
scalable. It can't be one size fits all, and it can't be hardcoded.
The general mechanism is a tuple:
role, actor, target.
Role is a string that describes what the user can do.
Actor is User or Group of users
Target is the container for the resources. In OpenStack, we have two:
Projects and Domains, but this is a mistake, as we could have used
Project for both.
If you were managing Wordpress deployments, the roles would be:
Administrator
Editor
Subscriber
Author
Contributor
And the Target would be the actual instance: and editor on one may be
an author on another.
The real power of this model comes in delegation. You want to know who
assigned what role to whom.
In OpenStack, we are working toward a unified delegation model, that
links short term delegations (Trusts and OAuth) with Role Assignments.
This is up for review here:
https://review.openstack.org/#/c/189816/15
There is a real need to be able to assign identities to non-human
entities, and to be able to delegate the appropriate permissions to
them. In FreeIPA, we are making more and more use of the Service
principals to do that.
>
>
>> kinda like in the Tomcat Webserver prior to hitting the servlet itself,
>> but in a python WSGI way instead. This part could and should be
>> dynamically fetched from the Keystone server. Only the scope check
>> needs to be done in a resource specific way. There is support at the
>> EJB/Hibernate layer for this kind of access control, too, and that may
>> be a better place to focus on completely. I suspect it is this kind of
>> "Dynamic Policy" stuff that Pedro is working on. Do we have docs for
>> that? I'd love to compare notes.
>>
>> I'm in the US, on East Coast time. THis is a short Week due to
>> Thanksgiving, but I'd love to have a video conference of some sort the
>> following week to sync up the lessons learned from both projects.
> Yes! Let's figure something out.
>
>
>
_______________________________________________
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
3099
days inactive
3101
days old
7 comments
3 participants
participants (3)
-
Adam Young -
Bill Burke -
Stian Thorgersen