On 3/1/07, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote:
...
ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/[EMAIL
PROTECTED]
sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active
In particular, if you look at the last one, this is dealing with Accounts.
Rather than looking at their Kerberos krb5Name at all, I do a direct
mapping if they have an active "full" account. All users have kerberos
principals, but not all users have "full" accounts. So in the case that
they don't have "full" accounts, I don't want them to just automatically be
able to search the directory with an authenticated view.
Thanks, this is really great feedback.
Can you clarify "full" user vs. "non-full"? Is the deal here that a
non-full user is one who is coming in from outside Stanford via
Shibboleth credentials, and who is then mapped to Kerberos credentials
for access to intra-enterprise services?
My only question here is if this is a reference to the strength of the
connection, but I'm guessing it isn't. One of the things OpenLDAP lets me
do is enforce encryption strength of connections. For example, in my ACL
files, I have:
...
which means the SASL SSF must be at least strength 56. Java and other
applications will by default connect via SASL/GSSAPI with *no* encryption
(yuck!).
JNDI uses an env property Context.SECURITY_AUTHENTICATION. The
javadoc states this can be "none", "simple", or "strong". In the
current BindHandler, this property is set to "simple" which then
AFAICK maps to the SimpleAuthenticator. Likely this is just another
mismatch between the client-side JNDI API and our needs as a server.
I'll note as a separate feature the need to specify the connection
strength for access control and open a JIRA issue.
Thanks again.
Enrique
