Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls UserServiceAdapter.deleteMembership().
- Add a permission to a role: POST /permissions with JSON containing role ID, owner key, and access type. Calls UserServiceAdapter.createPermission().
- Delete a permission from a role: DEL /permissions/permissionId. Calls UserServiceAdapter.deletePermission().
All three objects, Roles, Permissions, and Memberships, fall into the category of objects we already have which should never be directly queried from a curator in our code base, but rather obtained through the UserServiceAdatper.
Seem ok? I can elaborate on alternative approaches but at this point in time it seems like clarity and decisiveness is probably best. :)
Cheers,
Devan
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
- Add a permission to a role: POST /permissions with JSON containing
role ID, owner key, and access type. Calls UserServiceAdapter.createPermission().
- Delete a permission from a role: DEL /permissions/permissionId.
Calls UserServiceAdapter.deletePermission().
The above two points mean that a permission cannot exist on its own, right? it has to belong to exactly 1 role at all times. I like this.
All three objects, Roles, Permissions, and Memberships, fall into the category of objects we already have which should never be directly queried from a curator in our code base, but rather obtained through the UserServiceAdatper.
Seem ok? I can elaborate on alternative approaches but at this point in time it seems like clarity and decisiveness is probably best. :)
Seems ok (except for memberships, maybe).
Cheers,
Devan _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
On Wed, Jun 8, 2011 at 11:33 AM, James Bowes jbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
- Add a permission to a role: POST /permissions with JSON containing
role ID, owner key, and access type. Calls UserServiceAdapter.createPermission().
- Delete a permission from a role: DEL /permissions/permissionId.
Calls UserServiceAdapter.deletePermission().
The above two points mean that a permission cannot exist on its own, right? it has to belong to exactly 1 role at all times. I like this.
Correct. Right now Permissions can exist on their own and are re-used across Roles, this will change such that it belongs to a specific Role.
All three objects, Roles, Permissions, and Memberships, fall into the category of objects we already have which should never be directly queried from a curator in our code base, but rather obtained through the UserServiceAdatper.
Seem ok? I can elaborate on alternative approaches but at this point in time it seems like clarity and decisiveness is probably best. :)
Seems ok (except for memberships, maybe).
Cheers,
Devan _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowes jbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev of the API we can update the other resources to match.
- Add a permission to a role: POST /permissions with JSON containing
role ID, owner key, and access type. Calls UserServiceAdapter.createPermission().
- Delete a permission from a role: DEL /permissions/permissionId.
Calls UserServiceAdapter.deletePermission().
The above two points mean that a permission cannot exist on its own, right? it has to belong to exactly 1 role at all times. I like this.
Correct. Right now Permissions can exist on their own and are re-used across Roles, this will change such that it belongs to a specific Role.
All three objects, Roles, Permissions, and Memberships, fall into the category of objects we already have which should never be directly queried from a curator in our code base, but rather obtained through the UserServiceAdatper.
Seem ok? I can elaborate on alternative approaches but at this point in time it seems like clarity and decisiveness is probably best. :)
Seems ok (except for memberships, maybe).
Cheers,
Devan _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-- Devan Goodwin dgoodwin@rm-rf.ca http://rm-rf.ca _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
On 06/08/2011 10:49 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowesjbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev of the API we can update the other resources to match.
If we have the model where a Role == an ldap group.. then it is Many to Many.
-- bk
On Wed, Jun 8, 2011 at 11:57 AM, Bryan Kearney bkearney@redhat.com wrote:
On 06/08/2011 10:49 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowesjbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev of the API we can update the other resources to match.
If we have the model where a Role == an ldap group.. then it is Many to Many.
-- bk
Yeah it's just a question if it's Role ManyToMany with User, or Role OneToMany with an intermediate Membership object (which is just a Role and a User), but in both cases roles have many users and users have many roles.
Something else to remember with this, the roles are almost irrelevant to our application, it's basically an implementation detail that I suspect could be hidden behind the user service. All we really care about in Candlepin is ending up with a principal that has permissions. The roles are just how we get *some* of those permissions if you authenticate as a user and are using our default user service.
The LDAP user service can do whatever it wants behind the scenes, it just needs to get us a principal with the right permissions. If we keep these role/membership/permission methods on the user service adapter interface, the LDAP user service is going to just be throwing not implemented exceptions for them all. Possible in the future we'll want to take these off the user service interface.
On 06/08/2011 10:58 AM, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:57 AM, Bryan Kearneybkearney@redhat.com wrote:
On 06/08/2011 10:49 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowesjbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev of the API we can update the other resources to match.
If we have the model where a Role == an ldap group.. then it is Many to Many.
-- bk
Yeah it's just a question if it's Role ManyToMany with User, or Role OneToMany with an intermediate Membership object (which is just a Role and a User), but in both cases roles have many users and users have many roles.
Something else to remember with this, the roles are almost irrelevant to our application, it's basically an implementation detail that I suspect could be hidden behind the user service. All we really care about in Candlepin is ending up with a principal that has permissions. The roles are just how we get *some* of those permissions if you authenticate as a user and are using our default user service.
The LDAP user service can do whatever it wants behind the scenes, it just needs to get us a principal with the right permissions. If we keep these role/membership/permission methods on the user service adapter interface, the LDAP user service is going to just be throwing not implemented exceptions for them all. Possible in the future we'll want to take these off the user service interface.
I would make it as simple as possible. I envision the SAM Standalone UI being creating roles, adding permissions. And then adding roles to users. So.. I think straight Many to Many is fine.
KISS.
- bk
On Wed, Jun 8, 2011 at 12:08 PM, Bryan Kearney bkearney@redhat.com wrote:
On 06/08/2011 10:58 AM, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:57 AM, Bryan Kearneybkearney@redhat.com wrote:
On 06/08/2011 10:49 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:38:33AM -0300, Devan Goodwin wrote:
On Wed, Jun 8, 2011 at 11:33 AM, James Bowesjbowes@redhat.com wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote: > > Here is my current plan for refactoring and modelling the role to > user > and role to permission relationships as resources themselves. > > - Create a role with POST /roles (json blob containing not much more > than a name) Calls UserServiceAdapter.createRole which returns a role > with a unique ID. > > - Add a user to a role: POST /memberships with JSON containing just a > username and a role ID. Calls UserServiceAdapter.createMembership() > and returns a membership with a unique ID. > > - Delete a user from a role: DEL /memberships/membershipid. Calls > UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Rails tends to try to represent this type of membership as an actual resource with it's own distinct ID. Up until yesterday it was just a straight Role-User relationship and created/updated by posting JSON blobs with the users in it. As Justin pointed out this implies the caller has to know the full set of users before it can change anything, and introduces problems with race conditions. We can go back to straight Role-User and perhaps do something like POST /roles/id/users/username or DEL /roles/id/username to update the set. However current path was to treat the relationship like an actual resource. Should we revert to direct ManyToMany from Role to User?
If there's a reasoning behind it, then that's cool. Perhaps for next rev of the API we can update the other resources to match.
If we have the model where a Role == an ldap group.. then it is Many to Many.
-- bk
Yeah it's just a question if it's Role ManyToMany with User, or Role OneToMany with an intermediate Membership object (which is just a Role and a User), but in both cases roles have many users and users have many roles.
Something else to remember with this, the roles are almost irrelevant to our application, it's basically an implementation detail that I suspect could be hidden behind the user service. All we really care about in Candlepin is ending up with a principal that has permissions. The roles are just how we get *some* of those permissions if you authenticate as a user and are using our default user service.
The LDAP user service can do whatever it wants behind the scenes, it just needs to get us a principal with the right permissions. If we keep these role/membership/permission methods on the user service adapter interface, the LDAP user service is going to just be throwing not implemented exceptions for them all. Possible in the future we'll want to take these off the user service interface.
I would make it as simple as possible. I envision the SAM Standalone UI being creating roles, adding permissions. And then adding roles to users. So.. I think straight Many to Many is fine.
KISS.
- bk
Based on this I'm going to backtrack a bit. It is simpler to revert to the ManyToMany and add users by posting to things like /roles/id/users/username and /roles/id/permissions. Perhaps not as RESTful, but drastically less code. (resources, curators, user service adapter methods)
On 06/08/2011 10:33 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
Here is my current plan for refactoring and modelling the role to user and role to permission relationships as resources themselves.
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
- Add a user to a role: POST /memberships with JSON containing just a
username and a role ID. Calls UserServiceAdapter.createMembership() and returns a membership with a unique ID.
- Delete a user from a role: DEL /memberships/membershipid. Calls
UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Yeah.. why not
/users/{uuid}/roles? or /roles/users?
- Add a permission to a role: POST /permissions with JSON containing
role ID, owner key, and access type. Calls UserServiceAdapter.createPermission().
- Delete a permission from a role: DEL /permissions/permissionId.
Calls UserServiceAdapter.deletePermission().
The above two points mean that a permission cannot exist on its own, right? it has to belong to exactly 1 role at all times. I like this.
+1
All three objects, Roles, Permissions, and Memberships, fall into the category of objects we already have which should never be directly queried from a curator in our code base, but rather obtained through the UserServiceAdatper.
Seem ok? I can elaborate on alternative approaches but at this point in time it seems like clarity and decisiveness is probably best. :)
Seems ok (except for memberships, maybe).
I think that is fine. Our default
On 06/08/2011 04:27 PM, Devan Goodwin wrote:
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
Hi,
got a question. Looking at the ruby client there are some permissions stored with the role entity:
# TODO: drop perms here too? def create_role(name, perms=nil) perms ||= [] role = { :name => name, :permissions => perms, } post("/roles", role) end
What are these used for?
Thanks
On Wed, Jun 22, 2011 at 7:42 AM, Lukas Zapletal lzap+pub@redhat.com wrote:
On 06/08/2011 04:27 PM, Devan Goodwin wrote:
- Create a role with POST /roles (json blob containing not much more
than a name) Calls UserServiceAdapter.createRole which returns a role with a unique ID.
Hi,
got a question. Looking at the ruby client there are some permissions stored with the role entity:
# TODO: drop perms here too? def create_role(name, perms=nil) perms ||= [] role = { :name => name, :permissions => perms, } post("/roles", role) end
What are these used for?
Thanks
-- Later, Lukas "lzap" Zapletal
Just an initial set of permissions, rather than explicitly adding them one at a time. You can do it either way.
Cheers,
Devan
candlepin@lists.fedorahosted.org
-
Bryan Kearney -
Devan Goodwin -
James Bowes -
Lukas Zapletal