On Saturday 11 March 2006 21:32, Quanah Gibson-Mount wrote: > --On Saturday, March 11, 2006 7:34 PM -0500 "Michael J. Smith" <[EMAIL > PROTECTED]> > wrote:
> > Campus A may want to give wireless access to students and faculty of > > campus B, but only to faculty of campus C. [....] > 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". So -- following up my contrived scenario -- if we used this model, then anybody who was entitled to wireless access on Campus A would have to have CampusAWireless vel sim as one of the attributes of suprivilegegroup? > 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. This is interesting. How does the linkage between "people" entries and "account" entries work? If people can have multiple accounts, can multiple people share a single account? Do accounts have authentication info (passwords, public keys, etc.)? If I want wireless access, do I bind to my account or to my "people" entry, and if the latter, how does the account info get pulled into the picture? Do you folks have any design documents or white papers or such that explain the thinking behind your design? You've obviously put a lot of thought into it, and I imagine a good many other institutions could benefit from a better understanding of it. -- --Michael J. Smith [EMAIL PROTECTED] --- 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.
