www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Stevenson <pct...@apache.org>
Subject Re: Centralised authentication/authorisation
Date Sun, 07 Dec 2008 12:35:57 GMT


Aristedes Maniatis wrote:
> My LDAP experience is not as extensive as others here I'm sure, but the 
> proposed documentation raises some questions I haven't seen discussed here:

Don't let that hold you back. :-)

> * why has openldap been dismissed from consideration as a server? I'd 
> have thought it was one of the most used servers available?

Because we need try and find a server based product that is supported 
natively on each OS we use in infra.  I think the biggest concern 
amongst many was the issues with the Solaris native client.

We want to, infact I think I insist we need to use the native LDAP 
client so security updates et al, from the vendor can be applied.

> * I know phpldapadmin is clunky in many ways, but the fact that you can 
> create templates makes it one of the more user friendly admin tools for 
> people not familiar with the nuance of the ldap command line. It could 
> form the basis of a customised front end.

Not sure we would use this. Especially seeing as it is PHP.  All 
administration would most likely be restricted to prevent external 
access.  i.e. Using an LDAP client tunnelled over SSH, or better yet 
command line only :-)

This will not initially be public service, this will be an internal 
method for managing accounts.  If and when we goto an automated user 
account management, i.e. allowing user to reset passwords etc, then we 
may open it up in parts to the public network.

> * what objectClasses are being used? Will people be inetOrgPerson or 
> posixUser or a custom apachePerson class which all the appropriate 
> attributes brought together?

It will likely we a butchered version of inetOrgPerson. Accomodating 
many additional data fields.


> * will memberOf be used? I use the plugin for openldap to generate these 
> and they prove to be extremely useful for integrating with different 
> LDAP consumers.
> 
> * why are people divided into "ou=availid-a" groups? Are the speed 
> improvements worth this extra layer?

This is no longer going to be the case, this was a carry over from the 
SVN authorisation file that is currently in use.  You can quite easily 
ignore that now. I guess I should update the proposed schema.  :-)

> 
> * will email address be used as part of the dn or will they be given 
> some sort of unique number (eg. "uidNumber=1234, ou=people, dc=apache, 
> dc=org") Using an autogenerated id would appear to be much more robust 
> since then the dn is immutable through the change from outsider to 
> cla-user to committer to board, not to mention name (eg marriage) or 
> email changes. The proposed schema looks like 'username' is part of the 
> dn which might be troublesome on these counts.

Initially there will be one class of user.  Those who have an apache.org 
  account, i.e. those with an availid.  When we look to extend the use 
of LDAP to cover other public services such as Buzilla, JIRA, etc then 
we will look to create a 2nd class of user.  That class will most likely 
use an email address as the unique identifier.  The reason for this is 
to prevent folks from squatting namespace in the apache.org domain. 
i.e. You cant sign up to Jira, and effectively reserver 
nyname@apache.org. if you are invited to become a committer and the name 
you request if free, then fine, if not.  Then choose again.  Apparently 
there are people out there who are unscruplious enough to do this. :-)

> Please excuse me if these things have been already discussed and 
> resolved before.

It's always good to get another pair of eyes, and a fresh opinion on 
things.  You can maybe see something the rest of us have completely 
overlooked.

-- 


-----------------------------------------
Tony Stevenson
tony@pc-tony.com  //  pctony@apache.org
http://www.pc-tony.com/

1024D/51047D66 ECAF DC55 C608 5E82 0B5E  3359 C9C7 924E 5104 7D66
-----------------------------------------

Mime
View raw message