directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quanah Gibson-Mount <>
Subject Re: [SASL] SASL questions
Date Sun, 04 Mar 2007 04:33:25 GMT

--On Friday, March 02, 2007 1:57 PM -0800 Enrique Rodriguez 
<> wrote:

> On 3/1/07, Quanah Gibson-Mount <> wrote:
>> ...
>> ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5Principal
>> Name=webauth/$ sasl-regexp
>> uid=(.*),,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?

Well, no, we support Shibboleth separately from full vs base (non-full). 
It has more to do with say, contractors or other outside people who may 
need access to specific resources.


has a chart part way down describing the differences between base & full.


has more charts, and a broader description of base vs full.

>> 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.

Yeah, we have a number of Java apps using SASL/GSSAPI.  It was through them 
that we discovered Java's default behavior. ;)

One of my co-workers actually has a document on accessing LDAP with 


> I'll note as a separate feature the need to specify the connection
> strength for access control and open a JIRA issue.

Sounds good. :)


Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key:

View raw message