[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ACL/ACI && SASL
--On Thursday, June 26, 2003 1:34 PM -0700 Quanah Gibson-Mount
<quanah@stanford.edu> wrote:
Yes, but I'm on vacation the rest of this week, so it'll be on Monday.
Actually, I got a minute, so here goes...
We basically have 3 types of principles getting access from the directory:
Users (user@stanford.edu)
WebAuthentication (webauth/FQDN@stanford.edu)
Services (service/<servicename>@stanford.edu)
Users are stored by uid in the Accounts tree
(cn=accounts,dc=stanford,dc=edu)
WebAuth is stored in our Applications tree, in the webauth subtree
(cn=webauth,cn=applications,dc=stanford,dc=edu)
Service is stored in our Applications tree, in the Service subtree
(cn=service,cn=applications,dc=stanford,dc=edu)
In our slapd.conf file, we have the following regexp's:
sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldaps:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalNa
me=service/$1@stanford.edu
sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldaps:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalNa
me=webauth/$1@stanford.edu
sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldaps:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active
You'll notice that for users, we check against suSeasStatus=active, rather
than their krb5PrincipalName. That is because we have users who are not
qualified to query the openldap servers, but have Kerberos principles (we
call them base accounts).
For doing dynamic acl's, we use the group concept inside openldap. For
example, we have a group called webauthgeneral
(cn=webauthgeneral,cn=applications,dc=stanford,dc=edu).
It has various members, like:
member: cn=www,cn=webauth,cn=applications,dc=stanford,dc=edu
Each member is an "application process", for which we created the
"suApplication" objectclass.
An example entry is:
dn: cn=www,cn=Webauth,cn=applications,dc=stanford,dc=edu
objectClass: applicationProcess
objectClass: suApplication
objectClass: krb5Principal
cn: www
description: webauth access for www.stanford.edu
krb5PrincipalName: webauth/www.stanford.edu@stanford.edu
owner: <owner DN>
suAdministrator: <UID of owner>
In our slapd.acl file, we have things like:
access to attrs=uid,uidNumber,description
by group.base="cn=webauthgeneral,cn=applications,dc=stanford,dc=edu" read
by * break
We can now dynamically update another webauth application to have that
access level by simply creating an entry for them in the ldap server, and
adding them as a member of the webauthgeneral group. No stops/starts of
the server are required.
Basically, if you have a well defined set attributes you want to give
access to groups of individuals/applications, this makes it extremely
trivial to do.
--Quanah
--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html