--On Saturday, March 11, 2006 10:08 PM -0500 "Michael J. Smith" <[EMAIL PROTECTED]>
wrote:
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?
Well, not how Stanford does it. The accounts with wireless available on
Campus A would have something like an "objectClass: CampusAWirelessService"
that is AUX added, with and attribute named "suCampusAWirelessStatus" set
to "enabled".
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?
The account entry contains references back to the owner, via the following
attributes:
owner
seeAlso
suIdentifies
"suIdentifies" is used when the account is linked to a person (rather than
a department or other organization).
Multiple people cannot share accounts (nor do we intend to ever support
that, AFAIK).
As an example of multiple accounts, I have at least 3:
My primary ID, an ID I use for testing, and a "root" instance ID (related
to Kerberos V).
Our account tree does not have passwords in it, since all of our passwords
are stored in Kerberos which is where all authentication occurs. The LDAP
servers are used for authorizations.
Generally, people do not bind to their entries in the LDAP server at all.
In our case, applications bind to the LDAP servers, and then verify if a
given account has access to a particular resource (i.e., someone goes to
log into wireless. The wireless software does an LDAP lookup to see if
that ID has "wireless" service).
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.
Some of this is present at:
<http://www.stanford.edu/dept/as/mais/>
specifically:
<https://www.stanford.edu/dept/as/mais/integration/index.html>
However, this site is currently blocked off to Stanford only people for
reasons I don't understand. I've queried the group responsible (we've
undergone many reorgs in the last couple years, and that group is now in an
entirely different organization). I'll keep you posted on if/when it gets
opened up.
--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.
