2:33 p.m.
I'm trying to wrap my head around the use cases where each would be
used. If I understand it correctly, a role a unit of authorization.
Roles can have entitlements, either defined by Keycloak or an
application. A role can have other roles as members. It can also
have groups and individual users. Groups aren't directly linked to
entitlements, but are instead used to simply create a way to create a
set of users (and groups). Is this an accurate representation?
I ask because I want to build some integrations between OpenUnison and
MyVirtualDirectory. Both work primarily on the LDAP concepts of
users, groups and users. Beyond SSO integration between OpenUnison
and Keycloak, I'm looking at creating a provisioning target so
OpenUnison workflows can provision access to Keycloak roles as well
as an insert for MyVirtualDirectory that can represent Keycloak roles
and users as LDAP Objects for legacy applications.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
2:50 p.m.
I'm sure people will confuse Groups and Roles. Groups in LDAP generally
seem to be equivalent to Roles in Java EE. But that's not the case in
keycloak
Roles in Keycloak are similar to Java EE roles. Users are granted a
role, and become members of a Group. Groups in Keycloak are a
collection of users. Groups can have roles and attributes assigned to
them that user members inherit.
Clients/Applications work with roles, not with groups. Applications
assign privileges to roles, not users or groups. Keycloak currently
does not have the concept of Permissions/Entitlements. Applications
have to handle how privileges are assigned to a role themselves.
On 12/10/2015 3:33 PM, Marc Boorshtein wrote:
I'm trying to wrap my head around the use cases where each would
be
used. If I understand it correctly, a role a unit of authorization.
Roles can have entitlements, either defined by Keycloak or an
application. A role can have other roles as members. It can also
have groups and individual users. Groups aren't directly linked to
entitlements, but are instead used to simply create a way to create a
set of users (and groups). Is this an accurate representation?
I ask because I want to build some integrations between OpenUnison and
MyVirtualDirectory. Both work primarily on the LDAP concepts of
users, groups and users. Beyond SSO integration between OpenUnison
and Keycloak, I'm looking at creating a provisioning target so
OpenUnison workflows can provision access to Keycloak roles as well
as an insert for MyVirtualDirectory that can represent Keycloak roles
and users as LDAP Objects for legacy applications.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
_______________________________________________
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
3:09 p.m.
Roles in Keycloak are similar to Java EE roles. Users are granted a
role, and become members of a Group. Groups in Keycloak are a
collection of users. Groups can have roles and attributes assigned to
them that user members inherit.
OK, so let me see if i'm conceptualizing this correctly. I've created
a role called "MyRole". I have a group called "MyGroup" and a user
named Matt Mosley (mmosley). I can grant mmosley the role MyRole
directly or I can add mmosley to MyGroup and grant MyGroup MyRole?
Additionally if the group MyGroup has an attribute x with the value y
then mmosley, once assigned to MyGroup, would inherit the group
attribute x=y?
Clients/Applications work with roles, not with groups.
Applications
assign privileges to roles, not users or groups. Keycloak currently
does not have the concept of Permissions/Entitlements. Applications
have to handle how privileges are assigned to a role themselves.
I think we're saying the same thing here. Roles are the integration
point with KeyCloak (not groups) and its the application that gives a
role meaning.
So if I were to create a directory structure for an LDAP tree it would
probably look something like:
ou=keycloack
- ou=users
- uid=mmosley
- ou=groups
- cn=MyGroup
- ou=roles
- cn=myrole
- ou=app1
- cn=anAppSpecificRole
OpenUnison doesn't have the concept of "roles" vs "groups". So I
would probably have all roles start with a "role." and groups start
with a "group." so I can differentiate between them.
Am I on the right track? I've got Keycloak up and running so I'll
play around with the apis too but didn't want to do that in a vacuum.
Thanks
On 12/10/2015 3:33 PM, Marc Boorshtein wrote:
> I'm trying to wrap my head around the use cases where each would be
> used. If I understand it correctly, a role a unit of authorization.
> Roles can have entitlements, either defined by Keycloak or an
> application. A role can have other roles as members. It can also
> have groups and individual users. Groups aren't directly linked to
> entitlements, but are instead used to simply create a way to create a
> set of users (and groups). Is this an accurate representation?
>
> I ask because I want to build some integrations between OpenUnison and
> MyVirtualDirectory. Both work primarily on the LDAP concepts of
> users, groups and users. Beyond SSO integration between OpenUnison
> and Keycloak, I'm looking at creating a provisioning target so
> OpenUnison workflows can provision access to Keycloak roles as well
> as an insert for MyVirtualDirectory that can represent Keycloak roles
> and users as LDAP Objects for legacy applications.
>
> Thanks
>
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein(a)tremolosecurity.com
> _______________________________________________
> 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
5:48 a.m.
On 10/12/15 22:09, Marc Boorshtein wrote:
> Roles in Keycloak are similar to Java EE roles. Users are
granted a
> role, and become members of a Group. Groups in Keycloak are a
> collection of users. Groups can have roles and attributes assigned to
> them that user members inherit.
>
OK, so let me see if i'm conceptualizing this correctly. I've created
a role called "MyRole". I have a group called "MyGroup" and a user
named Matt Mosley (mmosley). I can grant mmosley the role MyRole
directly or I can add mmosley to MyGroup and grant MyGroup MyRole?
If you grant
mmosley the role MyRole directly, it will be granted just
to this user. If you grant MyRole to MyGroup, then the MyRole will be
granted to each user added to the MyGroup. So you will just put 2 users
to MyGroup: "mmosley", "mmosley2" and both will inherit MyRole.
Additionally if the group MyGroup has an attribute x with the value
y
then mmosley, once assigned to MyGroup, would inherit the group
attribute x=y?
yes
> Clients/Applications work with roles, not with groups. Applications
> assign privileges to roles, not users or groups. Keycloak currently
> does not have the concept of Permissions/Entitlements. Applications
> have to handle how privileges are assigned to a role themselves.
>
I think we're saying the same thing here. Roles are the integration
point with KeyCloak (not groups) and its the application that gives a
role meaning.
So if I were to create a directory structure for an LDAP tree it would
probably look something like:
ou=keycloack
- ou=users
- uid=mmosley
- ou=groups
- cn=MyGroup
- ou=roles
- cn=myrole
- ou=app1
- cn=anAppSpecificRole
OpenUnison doesn't have the concept of "roles" vs "groups". So
I
would probably have all roles start with a "role." and groups start
with a "group." so I can differentiate between them.
I am starting on
adding LDAP Group Mapper to Keycloak and it will be
(hopefully) available in 1.8. Mapper will allow you to specify in which
DN are your groups and in which DN(s) are your roles (LDAP RoleMapper is
already available, but I am planning some changes to 1.8, but it should
remain backwards compatible).
So for your LDAP tree example, if you configure mappers like:
- Group Mapper: ou=groups,ou=keycloak
- Role Mappper for realm roles: ou=roles,ou=keycloak
- Role Mapper for client roles of client "app1":
ou=app1,ou=roles,ou=keycloak
you will be able to map the environment. And you don't need to care
about the names of roles, groups etc. because:
- LDAP group "cn=MyGroup,ou=groups,ou=keycloak" will be automatically
treated as Keycloak group
- LDAP group "cn=myrole,ou=users,ou=keycloak" will be treated as
Keycloak realm role
- LDAP group "cn=anAppSpecificRole,cn=app1,ou=roles,ou=keycloak" will be
treated as client role of "app1" client
The Role Mapper is already available, so you can already try it out with
1.7.
Marek
Am I on the right track? I've got Keycloak up and running so I'll
play around with the apis too but didn't want to do that in a vacuum.
Thanks
> On 12/10/2015 3:33 PM, Marc Boorshtein wrote:
>> I'm trying to wrap my head around the use cases where each would be
>> used. If I understand it correctly, a role a unit of authorization.
>> Roles can have entitlements, either defined by Keycloak or an
>> application. A role can have other roles as members. It can also
>> have groups and individual users. Groups aren't directly linked to
>> entitlements, but are instead used to simply create a way to create a
>> set of users (and groups). Is this an accurate representation?
>>
>> I ask because I want to build some integrations between OpenUnison and
>> MyVirtualDirectory. Both work primarily on the LDAP concepts of
>> users, groups and users. Beyond SSO integration between OpenUnison
>> and Keycloak, I'm looking at creating a provisioning target so
>> OpenUnison workflows can provision access to Keycloak roles as well
>> as an insert for MyVirtualDirectory that can represent Keycloak roles
>> and users as LDAP Objects for legacy applications.
>>
>> Thanks
>>
>>
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein(a)tremolosecurity.com
>> _______________________________________________
>> 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
5:57 a.m.
On Dec 11, 2015 6:48 AM, "Marek Posolda" <
I am starting on adding LDAP Group Mapper to Keycloak and it will be
(hopefully) available in 1.8. Mapper will allow you to specify in which DN
are your groups and in which DN(s) are your roles (LDAP RoleMapper is
already available, but I am planning some changes to 1.8, but it should
remain backwards compatible).
Very nice, but this is so a legacy application can use keycloak via ldap.
It would be great if an application that only knows how to speak ldap could
use keycloak for authorization information. You can tell the app to look at
my virtual directory which in turn would make the web services calls. If I
use an http/2 implementation it would scale well too.
So for your LDAP tree example, if you configure mappers like:
- Group Mapper: ou=groups,ou=keycloak
- Role Mappper for realm roles: ou=roles,ou=keycloak
- Role Mapper for client roles of client "app1":
ou=app1,ou=roles,ou=keycloak
you will be able to map the environment. And you don't need to care about
the
names of roles, groups etc. because:
- LDAP group "cn=MyGroup,ou=groups,ou=keycloak" will be
automatically
treated as Keycloak group
- LDAP group "cn=myrole,ou=users,ou=keycloak" will be
treated as Keycloak
realm role
- LDAP group
"cn=anAppSpecificRole,cn=app1,ou=roles,ou=keycloak" will be
treated as
client role of "app1" client
The Role Mapper is already available, so you can already try it out with
1.7.
Marek
>
> Am I on the right track? I've got Keycloak up and running so I'll
> play around with the apis too but didn't want to do that in a vacuum.
>
> Thanks
>
>
>> On 12/10/2015 3:33 PM, Marc Boorshtein wrote:
>>>
>>> I'm trying to wrap my head around the use cases where each would be
>>> used. If I understand it correctly, a role a unit of authorization.
>>> Roles can have entitlements, either defined by Keycloak or an
>>> application. A role can have other roles as members. It can also
>>> have groups and individual users. Groups aren't directly linked to
>>> entitlements, but are instead used to simply create a way to create a
>>> set of users (and groups). Is this an accurate representation?
>>>
>>> I ask because I want to build some integrations between OpenUnison and
>>> MyVirtualDirectory. Both work primarily on the LDAP concepts of
>>> users, groups and users. Beyond SSO integration between OpenUnison
>>> and Keycloak, I'm looking at creating a provisioning target so
>>> OpenUnison workflows can provision access to Keycloak roles as well
>>> as an insert for MyVirtualDirectory that can represent Keycloak roles
>>> and users as LDAP Objects for legacy applications.
>>>
>>> Thanks
>>>
>>>
>>> Marc Boorshtein
>>> CTO Tremolo Security
>>> marc.boorshtein(a)tremolosecurity.com
>>> _______________________________________________
>>> 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
7:48 a.m.
On 12/10/2015 4:09 PM, Marc Boorshtein wrote:
>
> Roles in Keycloak are similar to Java EE roles. Users are granted a
> role, and become members of a Group. Groups in Keycloak are a
> collection of users. Groups can have roles and attributes assigned to
> them that user members inherit.
>
OK, so let me see if i'm conceptualizing this correctly. I've created
a role called "MyRole". I have a group called "MyGroup" and a user
named Matt Mosley (mmosley). I can grant mmosley the role MyRole
directly or I can add mmosley to MyGroup and grant MyGroup MyRole?
Additionally if the group MyGroup has an attribute x with the value y
then mmosley, once assigned to MyGroup, would inherit the group
attribute x=y?
> Clients/Applications work with roles, not with groups. Applications
> assign privileges to roles, not users or groups. Keycloak currently
> does not have the concept of Permissions/Entitlements. Applications
> have to handle how privileges are assigned to a role themselves.
>
I think we're saying the same thing here. Roles are the integration
point with KeyCloak (not groups) and its the application that gives a
role meaning.
So if I were to create a directory structure for an LDAP tree it would
probably look something like:
ou=keycloack
- ou=users
- uid=mmosley
- ou=groups
- cn=MyGroup
- ou=roles
- cn=myrole
- ou=app1
- cn=anAppSpecificRole
OpenUnison doesn't have the concept of "roles" vs "groups". So
I
would probably have all roles start with a "role." and groups start
with a "group." so I can differentiate between them.
Am I on the right track? I've got Keycloak up and running so I'll
play around with the apis too but didn't want to do that in a vacuum.
Yes, you are on the right track. we're always open to suggestions on
how to model things better too.
Also You could certainly populate group membership information in your
tokens/saml assertions and combine the concepts of group/role. But
Keycloak itself has separate meanings for them.
Also, Pedro is working a permission service based on UMA. You should be
seeing alphas/betas coming out soon.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:05 a.m.
Yes, you are on the right track. we're always open to suggestions on how to
model things better too.
Excellent. I really like the separation of roles and groups. It
creates a very clean logical break between the two. I usually do this
with most of my deployments from a conceptual standpoint but the fact
that its built into keycloak is very nice.
Also You could certainly populate group membership information in your
tokens/saml assertions and combine the concepts of group/role. But Keycloak
itself has separate meanings for them.
Makes sense. I tend to take an "all of the above" approach to
identity. So few applications follow consistent standards that I'd
rather have several options then be forced to use just one.
Also, Pedro is working a permission service based on UMA. You should be
seeing alphas/betas coming out soon.
Very nice. Looking forward to it!
3303
days inactive
3304
days old
6 comments
3 participants
participants (3)
-
Bill Burke -
Marc Boorshtein -
Marek Posolda