Quick Roles / Permissions Sanity Check

Bryan Kearney bkearney at redhat.com
Wed Jun 8 15:08:17 UTC 2011


On 06/08/2011 10:58 AM, Devan Goodwin wrote:
> On Wed, Jun 8, 2011 at 11:57 AM, Bryan Kearney<bkearney at 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 Bowes<jbowes at 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




More information about the candlepin mailing list