--On Saturday, March 11, 2006 7:34 PM -0500 "Michael J. Smith" <[EMAIL PROTECTED]>
wrote:
On Saturday 11 March 2006 17:27, Quanah Gibson-Mount wrote:
In any case, I think that it would be entirely possible to come up with
a set of attributes and rules to determine affiliation ordering for an
individual, but the more variables thrown in, the more complex it
certainly gets.
As far as I can tell, our problem is not so much priority of affiliation
as presenting the info in a way that applications can use for making
access-control decisions. Lots of policies are local. Contrived example:
Campus A may want to give wireless access to students and faculty of
campus B, but only to faculty of campus C. Not all these problems are
directory problems of course, but the directory problem, I guess, is to
try to anticipate the needs and limitations of the applications that are
going to be using it.
Ah, well, for policy based stuff, we have "workgroups". They are stored in
the directory as the attribute "suprivilegegroup". We have a frontend
application (workgroup.stanford.edu) that allows people to assign
privileges to various users, and then the directory is queried to see if a
given individual has access to resources, areas, etc, based on the values
of "suprivilegegroup".
We also have several instantiated workgroups (stanford:faculty,
stanford:staff, etc) that get added to people's privilege groups based on
their affiliations.
However, for things like wireless, we put those into the account entry
rather than the person entry (accounts are not people, and people can have
multiple accounts, etc, and there can be non-person accounts, etc). We
have a sponsorship application that allows people to sponsor other people
for particular services, and when they do that, an AUX objectClass is added
to their entry allowing them access to that account related resource.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
