On Thu, 2007-03-01 at 10:03 -0500, Stephane Bailliez wrote:
> Smith, Matt wrote:
> > UConn is inverting what you describe -- instead of using CAS for
> webdav,
> > etc, use a mechanism (Kerberos/LDAP) better suited for those non
> > browser-based services, and then use CAS to easily extend those
> > mechanisms to the browser environment.
>
> Yes, that would be my preference as well rather than having to bend so
> many things to integrate with CAS.
>
> Out of curiosity, how do you structure your LDAP ?
>
LDAP's structure is very simple - one big ou ("people") containing
~70,000 inetorgperson + eduperson objects. We supply some basic
attributes, but nothing service/application specific. Authentication
occurs against CAS & Kerberos (although we still do a bunch of LDAP
authentication, proxied back to Kerberos, for legacy reasons).
Authorization is handled by each service, either leveraging lists of
NetIDs (ACL) or accessing LDAP (and eventually Shibboleth and/or
CAS/SAML) to obtain user-centric attributes (affiliation, department,
etc). We do not store any service specific attributes in the directory
- in other words, there is no (and will not be) "allowAccessToServiceX"
in our LDAP. Services instead grant access using service-specific
instructions (ACI) equating to "allow access X to users of type Y",
where X is a service-specific type of access (read, write, change email
address, etc), and Y is some derivation of attributes (full-time
undergraduate students on main campus).BTW -- this kind of abstract, multi-technology, higher-ed centric discussion is good to have on the EDUCAUSE IdM list [EMAIL PROTECTED] HTH, -Matt -- Matthew J. Smith <[EMAIL PROTECTED]> University of Connecticut UITS
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
