directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quanah Gibson-Mount <qua...@stanford.edu>
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 
<enriquer9@gmail.com> wrote:

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

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.

<http://sunetid.stanford.edu/>

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

<http://www.stanford.edu/dept/as/mais/applications/sunetid/index.html>

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 
SASL/GSSAPI up:

<http://www.stanford.edu/~kam/ldap.html>


> 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

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Mime
View raw message