user roles

[Derek Atkins]

David Merrill <dmerrill@lupercalia.net> writes:

> Because it is so much more manageable when you have sets of users who
> all have the same permissions. Maybe that's not the situation I should
> be optimizing, though.

When you have sets of users, you create a group (role) and then acl
the group; then you can add and remove users from that group
dynamically and everyone obtains the priviledges of that group
membership.  But this is orthogonal to having ACLs with both users and
groups on it.

> Can you show me how you would store rights assigned to a specific user
> in the same table in which you store group (role) rights, then?

Well, I don't know enough SQL to be able to do it right, but basically
in pseudo-IDL:

Acl ::= {
	AclEntry[]	AclList
}

AclEntry ::= {
	int		type			<group or user>
	GUID		NameID			<GroupID or UserID>
	BitSet		Priviledges
}

Group ::= {
	GUID		GroupID
	GUID[]		MembersList
	...
}

User ::= {
	GUID		UserID
	...
}

Then any other object just needs to include an Acl..  Now, I know this
is not a direct representation in SQL, but perhaps you can see what
I'm trying to do?  And yes, users can be members of multiple groups,
at least in my model.  When looking at priviledges, you get the union
of all priviledges on the ACL.

> Because the db doesn't work with names; it works with guids, and there
> are referential integrity rules to think of.

Could you please explain what "referential integrity rules" there are
and how they apply?

> Here are the table structures (simplified) I'm looking at right now:
>
> USER
> ----
> dbuser_guid
> 
> ROLE
> ----
> role_guid
> set of permissions
> 
> USER_ROLE
> ---------
> dbuser_guid
> role_guid

This looks like the permissions are assigned to a role directly.
That's wrong (and backwards).  A role doesn't have any permissions by
itself.  Indeed, that's why I keep referring to it as a group, not a
role.  Anyways, an _object_ assigns a set of permissions to a group.
A role is just a grouping of users who all get the same permissions,
but those permissions are not inherent in the role, they are assigned
by various objects in the datastore.  In other words, a role is just a
convienient way to assign permissions but allow the actual users to
change over time.

For example, you have a role (group) of users called "accounts
receivable data entry".  Obviously, your team of workers can change
over time, so membership in this group will change as well.  Then you
add that group to the acl on a set of accounts, where each account may
assign different permissions to that particular group.  For example,
you probably don't want to grant access to the payroll accounts to
this group.  In order to have this functionality, permissions for the
group must be tied to the object being protected, not to the group
itself.

> user_role, iow, assigns a role to the user. The permissions are in the
> role table. Using my latest proposal, you would have a role record for
> each user, created automatically when you create a user. Assigning
> rights to the user specifically is a matter of changing the
> permissions in this record.

But you need to be able to set the rights based on the various objects
in the system.  How would you assign the rights to, say, read current
transactions but not previous transactions?

> See, I'm thinking at the level of the data tables, and how to
> represent the permissions and roles. Presenting it in another format
> to the client is easy, and a different problem. The api would have a
> function for "assign this right to this user" and a different funtion
> for "assign this right to this group", and so the db knows where,
> specifically, to store the new rights.

Fair enough..  I'm just trying to make sure the permission system is
flexible.  I agree that how it is presented vs. how it is stored are
somewhat orthogonal issues.  OTOH, how it is stored will directly
affect how versatile the acl system is.  And FTR, I have designed ACL
systems in the past (although not in SQL ;).

> And I'm not recommending separate lists for groups and users. I am in
> fact proposing a way around doing that. I thought when you said to
> assign permissions directly to users you intended to add the "set of
> permissions" fields directly into the dbuser table. I think now I
> might have misunderstood.

No, I'm proposing that permissions are stored with neither users nor
roles; permissions are stored with objects, and objects assign
permissions to users OR groups/roles.  Roles are just a convenient way
to abstract away the set of users who get those permissions.  This
allows you to change the group membership without having to reACL
everything.

> I'm beginning to think we're talking past each other?

Perhaps, but I think we're really just looking at things differently.
You're looking at roles having predefined permissions, and I'm looking
at roles as really just a group of users, and permissions for that
role can vary throughout the database.

> Yeah, we'll get there eventually.

Progress is being made ;)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available