You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Tony Stevenson <pc...@apache.org> on 2008/11/20 18:54:25 UTC
Centralised authentication/authorisation
For some time now I been making some tongue in cheek comments stating that
the ASF should look at using some form of centralised authentication
and/or authorisation.
We, the infra team, currently manage the access to services such as:
* Subversion
* Shell access to people.apache.org
* Bugzilla
* Confluence
* JIRA
* cwiki
This means that folks who have access to any or all of these systems will
have an individual accounts for each service. This seems daft with over
2000 committers now, with this number rising each week this will become
more difficult to reliably sustain.
So what I want to do now, is formally propose that we consider deploying the
services of LDAP directory services. This can be used for not only
centralised authentication/authorisation but also for:
* Storing copies of committers public keys.
* Storing a copy of users' associated ICLA
* Contact information at least for all members, but possibly committers too.
A few people have helped start gathering requirements, and ideas here ->
https://svn.eu.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
That folder is currently available for all committers to look over. But
not write too.
The current docs are by no means complete, and I am looking for other
folks to help me get them to a state so that we can present the idea and
kick the project off. There are some technical requirements that are
non-negotiable, for instance:
* Multi site master (For HA)
* Intra site replication (To maintain said HA)
* No direct internet access to LDAP (obvious, but, security)
There are some other ideas in the documentation in subversion, like karma
attribution amongst others.
Clearly most of the wish list items will require a custom user schema to
be used to store the relevant information.
I am happy to run with this, but I am looking for input from folks willing
to either help and/or get involved.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by sebb <se...@gmail.com>.
On 27/11/2008, Upayavira <uv...@odoko.co.uk> wrote:
> On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
> > For some time now I been making some tongue in cheek comments stating that
> > the ASF should look at using some form of centralised authentication
> > and/or authorisation.
> >
> > We, the infra team, currently manage the access to services such as:
> >
> > * Subversion
> > * Shell access to people.apache.org
> > * Bugzilla
> > * Confluence
> > * JIRA
> > * cwiki
> >
> > This means that folks who have access to any or all of these systems will
> > have an individual accounts for each service. This seems daft with over
> > 2000 committers now, with this number rising each week this will become
> > more difficult to reliably sustain.
> >
> > So what I want to do now, is formally propose that we consider deploying the
> > services of LDAP directory services. This can be used for not only
> > centralised authentication/authorisation but also for:
> >
> > * Storing copies of committers public keys.
> > * Storing a copy of users' associated ICLA
> > * Contact information at least for all members, but possibly committers too.
> >
> > A few people have helped start gathering requirements, and ideas here ->
> >
> > https://svn.eu.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
> >
> > That folder is currently available for all committers to look over. But
> > not write too.
> >
> > The current docs are by no means complete, and I am looking for other
> > folks to help me get them to a state so that we can present the idea and
> > kick the project off. There are some technical requirements that are
> > non-negotiable, for instance:
> >
> > * Multi site master (For HA)
> > * Intra site replication (To maintain said HA)
> > * No direct internet access to LDAP (obvious, but, security)
> >
> > There are some other ideas in the documentation in subversion, like karma
> > attribution amongst others.
> >
> > Clearly most of the wish list items will require a custom user schema to
> > be used to store the relevant information.
> >
> > I am happy to run with this, but I am looking for input from folks willing
> > to either help and/or get involved.
>
>
> The biggest issue that I do not yet see resolved is that of username
> namespaces.
+1
> Currently, we have a 'committer' namespace, names are allocated, by
> root, based upon requests from the new committer, when their Apache
> account is created.
And this namespace must map to names that are valid as login names.
> If we go to an LDAP setup that covers non-committers too, then we have
> to expand our namespace handing to cover names that non-committers might
> choose.
>
> And, we need to work out a way to handle the transition from
> non-committer to committer, in the (likely) case that that involves a
> change in username.
>
> Otherwise, we could get folks snapping up all the best names in the
> @apache.org namespace in the hope that they may one day become a
> committer, rather than having a name selected for them at the point at
> which their account is created.
How about insisting that the free-for-all LDAP entries (Bugzilla, JIRA
etc) use a valid e-mail address as the unique account id (e.g. by
requiring a confirmation e-mail)?
Until a user is a committer, they will not be able to use an @a.o address.
When a user accepts the invitation to become a committer, they would
be asked to set up an LDAP entry with the e-mail address that they
used in the ICLA (if they have not done so already).
This would be used as part of the login validation process. [If their
e-mail address on the CLA has changed since it was submitted, then
they would have to send in another.]
There would need to be some way to relate account ids to each other.
> In comparison to this, setting up LDAP itself seems easy :-)
>
>
> Upayavira
Re: Centralised authentication/authorisation
Posted by sebb <se...@gmail.com>.
On 27/11/2008, Upayavira <uv...@odoko.co.uk> wrote:
> On Thu, 2008-11-27 at 12:41 +0200, Graham Leggett wrote:
> > Upayavira wrote:
> >
> > > The biggest issue that I do not yet see resolved is that of username
> > > namespaces.
> > >
> > > Currently, we have a 'committer' namespace, names are allocated, by
> > > root, based upon requests from the new committer, when their Apache
> > > account is created.
> > >
> > > If we go to an LDAP setup that covers non-committers too, then we have
> > > to expand our namespace handing to cover names that non-committers might
> > > choose.
> > >
> > > And, we need to work out a way to handle the transition from
> > > non-committer to committer, in the (likely) case that that involves a
> > > change in username.
> > >
> > > Otherwise, we could get folks snapping up all the best names in the
> > > @apache.org namespace in the hope that they may one day become a
> > > committer, rather than having a name selected for them at the point at
> > > which their account is created.
> >
> > I generally approach this by using an email address as the account
> > identifier.
> >
> > When at some future date a user warrants committership, they get a uid
> > attribute added as appropriate.
>
>
> This starts to get us closer. SVN would of course authenticate against
> the UID, but that is fine, as it is only relevant to committers.
> Likewise shell access on people.apache.org.
>
> Jira, Confluence, Bugzilla should all be able to accept an email address
> as their unique ID. Moin however will not accept an email address
> (alphanumeric only), so we'd need to work something else out there
> (simply strip @ and . from the email address??)
>
However, Moin requires a valid e-mail address when registering (if
not, it should).
Hopefully, this could be used as the key when validating the user.
> Upayavira
>
>
>
>
>
Re: Centralised authentication/authorisation
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, 2008-11-27 at 14:58 +0200, Graham Leggett wrote:
> Upayavira wrote:
>
> > Jira, Confluence, Bugzilla should all be able to accept an email address
> > as their unique ID. Moin however will not accept an email address
> > (alphanumeric only), so we'd need to work something else out there
> > (simply strip @ and . from the email address??)
>
> I configured Moin at a client where the userid was an email address
> (actually, it was an active directory user principle name, which is in
> the same format as an email address). While it may have been true of
> older versions of Moin, it wasn't still the case for us.
>
> Moin was configured to auto-register the user if present, so end users
> didn't have to go through any external Moin specific registration
> process to keep Moin happy - if they were logged in to httpd, and they
> hit Moin, Moin would magically be editable without the user having to do
> anything (except be logged in).
Great.
Upayavira
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Upayavira wrote:
> Jira, Confluence, Bugzilla should all be able to accept an email address
> as their unique ID. Moin however will not accept an email address
> (alphanumeric only), so we'd need to work something else out there
> (simply strip @ and . from the email address??)
I configured Moin at a client where the userid was an email address
(actually, it was an active directory user principle name, which is in
the same format as an email address). While it may have been true of
older versions of Moin, it wasn't still the case for us.
Moin was configured to auto-register the user if present, so end users
didn't have to go through any external Moin specific registration
process to keep Moin happy - if they were logged in to httpd, and they
hit Moin, Moin would magically be editable without the user having to do
anything (except be logged in).
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, 2008-11-27 at 12:41 +0200, Graham Leggett wrote:
> Upayavira wrote:
>
> > The biggest issue that I do not yet see resolved is that of username
> > namespaces.
> >
> > Currently, we have a 'committer' namespace, names are allocated, by
> > root, based upon requests from the new committer, when their Apache
> > account is created.
> >
> > If we go to an LDAP setup that covers non-committers too, then we have
> > to expand our namespace handing to cover names that non-committers might
> > choose.
> >
> > And, we need to work out a way to handle the transition from
> > non-committer to committer, in the (likely) case that that involves a
> > change in username.
> >
> > Otherwise, we could get folks snapping up all the best names in the
> > @apache.org namespace in the hope that they may one day become a
> > committer, rather than having a name selected for them at the point at
> > which their account is created.
>
> I generally approach this by using an email address as the account
> identifier.
>
> When at some future date a user warrants committership, they get a uid
> attribute added as appropriate.
This starts to get us closer. SVN would of course authenticate against
the UID, but that is fine, as it is only relevant to committers.
Likewise shell access on people.apache.org.
Jira, Confluence, Bugzilla should all be able to accept an email address
as their unique ID. Moin however will not accept an email address
(alphanumeric only), so we'd need to work something else out there
(simply strip @ and . from the email address??)
Upayavira
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Upayavira wrote:
> The biggest issue that I do not yet see resolved is that of username
> namespaces.
>
> Currently, we have a 'committer' namespace, names are allocated, by
> root, based upon requests from the new committer, when their Apache
> account is created.
>
> If we go to an LDAP setup that covers non-committers too, then we have
> to expand our namespace handing to cover names that non-committers might
> choose.
>
> And, we need to work out a way to handle the transition from
> non-committer to committer, in the (likely) case that that involves a
> change in username.
>
> Otherwise, we could get folks snapping up all the best names in the
> @apache.org namespace in the hope that they may one day become a
> committer, rather than having a name selected for them at the point at
> which their account is created.
I generally approach this by using an email address as the account
identifier.
When at some future date a user warrants committership, they get a uid
attribute added as appropriate.
This has the added advantage of making it very hard/impossible for an
account to be created for someone by mistake.
> In comparison to this, setting up LDAP itself seems easy :-)
Getting your data model right is probably about 99% of the problem, yes.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> Agreed, this is something I was looking at. I was hoping to find a way
> for non committers usernames to have -pub tagged on the end.
> potentially looking at a sign up page, that would create accounts in
> LDAP with this tagged on the end. Maybe even a self service page, that
> used email verification.
>
> So any accounts that are created by root@ as part of the committer
> process would be manually created, and obviously not have the -pub, thus
> preventing namespace squatting.
There is a big potential problem with this approach - people will not
get the choice to choose their usernames, and in the process they will
not remember them.
This will generate a support burden where people will ask "what is my
username?". If you build them a tool that looks up their username based
on email address, you've reached the point where you might as well just
use the email address.
Also keep in mind that identifiers change over time. Today it is a
username or email address, tomorrow it might be openid.
We need to make sure that the LDAP schema has room to grow.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
sebb wrote:
> On 27/11/2008, Tony Stevenson <pc...@apache.org> wrote:
>> Upayavira wrote:
>> > On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
>>
>>
>> [SNIP ...]
>>
>>
>> >
>> > The biggest issue that I do not yet see resolved is that of username
>> > namespaces.
>> >
>> > Currently, we have a 'committer' namespace, names are allocated, by
>> > root, based upon requests from the new committer, when their Apache
>> > account is created.
>> >
>> > If we go to an LDAP setup that covers non-committers too, then we have
>> > to expand our namespace handing to cover names that non-committers might
>> > choose.
>>
>>
>> Agreed, this is something I was looking at. I was hoping to find a way
>> for non committers usernames to have -pub tagged on the end.
>> potentially looking at a sign up page, that would create accounts in
>> LDAP with this tagged on the end. Maybe even a self service page, that
>> used email verification.
>
> Much the same as per my recent e-mail.
>
>> So any accounts that are created by root@ as part of the committer
>> process would be manually created, and obviously not have the -pub, thus
>> preventing namespace squatting.
>>
>
> Using e-mail verification should prevent any such squatting.
>
>> >
>> > And, we need to work out a way to handle the transition from
>> > non-committer to committer, in the (likely) case that that involves a
>> > change in username.
>>
>>
>> If we use something similar to that above, and if they become a
>> committer and their requested name is not in use then thry can have it,
>> much like they can now. If it isn't free then they need to choose
>> again. :-)
>>
>> Simple, really...
>>
>>
>>
>> >
>> > Otherwise, we could get folks snapping up all the best names in the
>> > @apache.org namespace in the hope that they may one day become a
>> > committer, rather than having a name selected for them at the point at
>> > which their account is created.
>>
>>
>> Cheeky buggers. Who'd of thought people would be so cheeky :-)
>>
>>
>> >
>> > In comparison to this, setting up LDAP itself seems easy :-)
>>
>>
>> Here's hoping.
>>
>> Let me re-iterate, the next thing we all need to agree upon is the LDAP
>> schema, nothing will progress without this. I will try to expand the
>> current schema I added to SVN, and lets see if it sparks a flurry of
>> conversation.
>>
>
> But surely the schema depends at least partly on how it is to be used?
>
> Or is the idea to produce an initial schema, and see if that supports
> the various use cases, and then update the schema as required?
That's spot on. For now. The initial schema is the first milestone I
have set us before we proceed any further, this seems to be the
consensus amongst others too.
If we have a base schema, we can quite happily change that to suit, up
until we have a final, and agreed, schema that will support everything
we want it too.
Using an email address as an identifier, is quite simple. Let's see how
that that pans out.
I have an email from Emmanuel Lecharny in my inbox which I need to
digest and incorporate into the proposal. I am hoping that I will find
time to do this on Sunday.
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by sebb <se...@gmail.com>.
On 27/11/2008, Tony Stevenson <pc...@apache.org> wrote:
> Upayavira wrote:
> > On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
>
>
> [SNIP ...]
>
>
> >
> > The biggest issue that I do not yet see resolved is that of username
> > namespaces.
> >
> > Currently, we have a 'committer' namespace, names are allocated, by
> > root, based upon requests from the new committer, when their Apache
> > account is created.
> >
> > If we go to an LDAP setup that covers non-committers too, then we have
> > to expand our namespace handing to cover names that non-committers might
> > choose.
>
>
> Agreed, this is something I was looking at. I was hoping to find a way
> for non committers usernames to have -pub tagged on the end.
> potentially looking at a sign up page, that would create accounts in
> LDAP with this tagged on the end. Maybe even a self service page, that
> used email verification.
Much the same as per my recent e-mail.
> So any accounts that are created by root@ as part of the committer
> process would be manually created, and obviously not have the -pub, thus
> preventing namespace squatting.
>
Using e-mail verification should prevent any such squatting.
>
> >
> > And, we need to work out a way to handle the transition from
> > non-committer to committer, in the (likely) case that that involves a
> > change in username.
>
>
> If we use something similar to that above, and if they become a
> committer and their requested name is not in use then thry can have it,
> much like they can now. If it isn't free then they need to choose
> again. :-)
>
> Simple, really...
>
>
>
> >
> > Otherwise, we could get folks snapping up all the best names in the
> > @apache.org namespace in the hope that they may one day become a
> > committer, rather than having a name selected for them at the point at
> > which their account is created.
>
>
> Cheeky buggers. Who'd of thought people would be so cheeky :-)
>
>
> >
> > In comparison to this, setting up LDAP itself seems easy :-)
>
>
> Here's hoping.
>
> Let me re-iterate, the next thing we all need to agree upon is the LDAP
> schema, nothing will progress without this. I will try to expand the
> current schema I added to SVN, and lets see if it sparks a flurry of
> conversation.
>
But surely the schema depends at least partly on how it is to be used?
Or is the idea to produce an initial schema, and see if that supports
the various use cases, and then update the schema as required?
>
> Cheers,
> Tony
>
>
>
> --
>
>
> -----------------------------------------
> 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
> -----------------------------------------
>
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Upayavira wrote:
> On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
[SNIP ...]
>
> The biggest issue that I do not yet see resolved is that of username
> namespaces.
>
> Currently, we have a 'committer' namespace, names are allocated, by
> root, based upon requests from the new committer, when their Apache
> account is created.
>
> If we go to an LDAP setup that covers non-committers too, then we have
> to expand our namespace handing to cover names that non-committers might
> choose.
Agreed, this is something I was looking at. I was hoping to find a way
for non committers usernames to have -pub tagged on the end.
potentially looking at a sign up page, that would create accounts in
LDAP with this tagged on the end. Maybe even a self service page, that
used email verification.
So any accounts that are created by root@ as part of the committer
process would be manually created, and obviously not have the -pub, thus
preventing namespace squatting.
>
> And, we need to work out a way to handle the transition from
> non-committer to committer, in the (likely) case that that involves a
> change in username.
If we use something similar to that above, and if they become a
committer and their requested name is not in use then thry can have it,
much like they can now. If it isn't free then they need to choose
again. :-)
Simple, really...
>
> Otherwise, we could get folks snapping up all the best names in the
> @apache.org namespace in the hope that they may one day become a
> committer, rather than having a name selected for them at the point at
> which their account is created.
Cheeky buggers. Who'd of thought people would be so cheeky :-)
>
> In comparison to this, setting up LDAP itself seems easy :-)
Here's hoping.
Let me re-iterate, the next thing we all need to agree upon is the LDAP
schema, nothing will progress without this. I will try to expand the
current schema I added to SVN, and lets see if it sparks a flurry of
conversation.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
> For some time now I been making some tongue in cheek comments stating that
> the ASF should look at using some form of centralised authentication
> and/or authorisation.
>
> We, the infra team, currently manage the access to services such as:
>
> * Subversion
> * Shell access to people.apache.org
> * Bugzilla
> * Confluence
> * JIRA
> * cwiki
>
> This means that folks who have access to any or all of these systems will
> have an individual accounts for each service. This seems daft with over
> 2000 committers now, with this number rising each week this will become
> more difficult to reliably sustain.
>
> So what I want to do now, is formally propose that we consider deploying the
> services of LDAP directory services. This can be used for not only
> centralised authentication/authorisation but also for:
>
> * Storing copies of committers public keys.
> * Storing a copy of users' associated ICLA
> * Contact information at least for all members, but possibly committers too.
>
> A few people have helped start gathering requirements, and ideas here ->
>
> https://svn.eu.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>
> That folder is currently available for all committers to look over. But
> not write too.
>
> The current docs are by no means complete, and I am looking for other
> folks to help me get them to a state so that we can present the idea and
> kick the project off. There are some technical requirements that are
> non-negotiable, for instance:
>
> * Multi site master (For HA)
> * Intra site replication (To maintain said HA)
> * No direct internet access to LDAP (obvious, but, security)
>
> There are some other ideas in the documentation in subversion, like karma
> attribution amongst others.
>
> Clearly most of the wish list items will require a custom user schema to
> be used to store the relevant information.
>
> I am happy to run with this, but I am looking for input from folks willing
> to either help and/or get involved.
The biggest issue that I do not yet see resolved is that of username
namespaces.
Currently, we have a 'committer' namespace, names are allocated, by
root, based upon requests from the new committer, when their Apache
account is created.
If we go to an LDAP setup that covers non-committers too, then we have
to expand our namespace handing to cover names that non-committers might
choose.
And, we need to work out a way to handle the transition from
non-committer to committer, in the (likely) case that that involves a
change in username.
Otherwise, we could get folks snapping up all the best names in the
@apache.org namespace in the hope that they may one day become a
committer, rather than having a name selected for them at the point at
which their account is created.
In comparison to this, setting up LDAP itself seems easy :-)
Upayavira
AW: AW: Centralised authentication/authorisation
Posted by Juergen Hoffmann <ho...@apache.org>.
Hi,
that is exactly what I meant. I find it very useful. Plus I can grant certain users privileges to run a certain command on a certain host. But then again, you can do the exact same thing with the sudoers file.
It is probably best to focus on the important parts first, and migrate minor considerations when time slots are available. I just thought that this might find its place on the wishlist.
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Upayavira [mailto:uv@odoko.co.uk]
> Gesendet: Dienstag, 25. November 2008 14:34
> An: infrastructure-dev
> Betreff: Re: AW: Centralised authentication/authorisation
>
> (resending to infra-dev after bad typing sent it to infra@)
>
> On Tue, 2008-11-25 at 13:35 +0100, Jürgen Hoffmann wrote:
> > Hi,
> >
> > it still hast o be discussed if we want to use sudo LDAP Integration.
> > We like it very much inside our company.
>
> Do you mean storing the contents of the sudoers file in LDAP?
>
> If so, I'm saying we shouldn't be doing that at this point. The number
> of people who have that right is minuscule in comparison to the number
> of committers and users using SVN, Jira, confluence, etc. That is the
> area we should be focusing on, not on our tiny (in comparison)
> admin/infra team.
>
> UpayaviraOn Tue, 2008-11-25 at 13:35 +0100, Jürgen Hoffmann wrote:
> > Hi,
> >
> > it still hast o be discussed if we want to use sudo LDAP Integration.
> We
> > like it very much inside our company.
>
> Do you mean storing the contents of the sudoers file in LDAP?
>
> If so, I'm saying we shouldn't be doing that at this point. The number
> of people who have that right is minuscule in comparison to the number
> of committers and users using SVN, Jira, confluence, etc. That is the
> area we should be focusing on, not on our tiny (in comparison)
> admin/infra team.
>
> Upayavira
Re: AW: Centralised authentication/authorisation
Posted by Upayavira <uv...@odoko.co.uk>.
(resending to infra-dev after bad typing sent it to infra@)
On Tue, 2008-11-25 at 13:35 +0100, Jürgen Hoffmann wrote:
> Hi,
>
> it still hast o be discussed if we want to use sudo LDAP Integration.
> We like it very much inside our company.
Do you mean storing the contents of the sudoers file in LDAP?
If so, I'm saying we shouldn't be doing that at this point. The number
of people who have that right is minuscule in comparison to the number
of committers and users using SVN, Jira, confluence, etc. That is the
area we should be focusing on, not on our tiny (in comparison)
admin/infra team.
UpayaviraOn Tue, 2008-11-25 at 13:35 +0100, Jürgen Hoffmann wrote:
> Hi,
>
> it still hast o be discussed if we want to use sudo LDAP Integration.
We
> like it very much inside our company.
Do you mean storing the contents of the sudoers file in LDAP?
If so, I'm saying we shouldn't be doing that at this point. The number
of people who have that right is minuscule in comparison to the number
of committers and users using SVN, Jira, confluence, etc. That is the
area we should be focusing on, not on our tiny (in comparison)
admin/infra team.
Upayavira
AW: Centralised authentication/authorisation
Posted by Jürgen Hoffmann <ju...@heagmedianet.de>.
Hi,
it still hast o be discussed if we want to use sudo LDAP Integration. We
like it very much inside our company.
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Upayavira [mailto:uv@odoko.co.uk]
> Gesendet: Dienstag, 25. November 2008 11:18
> An: infrastructure-dev@apache.org
> Betreff: Re: Centralised authentication/authorisation
>
> On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
> >
> > Tony Stevenson wrote:
> >
> > >
> > > A few people have helped start gathering requirements, and ideas
> here ->
> > >
> > >
> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-
> project/
> > >
> >
> > I have just updated these a little.
> >
> >
> > Leading on from this, there are several steps that need to be
> > considered. This primarily revolves around the schema design, and
> which
> > product(s) should be considered.
> >
> > Does anyone have any ideas how you think the schema should look?
> There
> > is an initial document in the SVN repo.
> >
> > What about the concepts of using Kerberos and/or certificated?
>
> My one thought from browsing the proposed schema is that we have two
> use
> cases, committers and admins. Personally, at this point in time, I
> think
> we should be focussing on committers. That is where the scaling issues
> are. Adding Jack Black as root on hermes is a simple one off job that
> doesn't happen too often, so we can stick with our current scheme for
> the time being.
>
> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
> Moin and Confluence will be enough work as it is!
>
> Upayavira
>
>
Re: AW: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Juergen Hoffmann wrote:
>> Bugzilla integrates nicely with the mod_auth_* modules as well on a
>> much
>> simpler level.
>
> [JH> ] What do you mean by much simpler level?
As in you don't have to configure bugzilla to connect to or care about
an LDAP server, you just tell it "your user can be found in these
environment variables, enjoy".
Regards,
Graham
--
AW: Centralised authentication/authorisation
Posted by Juergen Hoffmann <ho...@apache.org>.
Hi,
> Bugzilla integrates nicely with the mod_auth_* modules as well on a
> much
> simpler level.
[JH> ] What do you mean by much simpler level?
> The modules are capable of exporting the user's name, email address,
> and
> any other details you like into the environment, and bugzilla can pick
> those details up from the environment, silently auto-creating the user
> if necessary.
[JH> ] That's nice
Kind regards
Juergen
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
>> Bugzilla integrates nicely with the mod_auth_* modules as well on a
>> much simpler level.
>>
>> The modules are capable of exporting the user's name, email address,
>> and any other details you like into the environment, and bugzilla can
>> pick those details up from the environment, silently auto-creating the
>> user if necessary.
>>
>
> Not sure I am comfortable with silent auto-creation of anything, let
> alone users :-)
I meant the autocreation of users in Bugzilla, not autocreation of users
in general.
The user would already be known to the ASF, and would have already
logged in, so there would be no point in expecting Bugzilla to ask the
user to tell it information that the httpd instance running above it
already knows with certainty.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Philip M. Gollucci wrote:
>
>>> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
>>> Moin and Confluence will be enough work as it is!
>> Bugzilla integrates with LDAP already too and AD even (shudder).
>
> Bugzilla integrates nicely with the mod_auth_* modules as well on a much
> simpler level.
>
> The modules are capable of exporting the user's name, email address, and
> any other details you like into the environment, and bugzilla can pick
> those details up from the environment, silently auto-creating the user
> if necessary.
>
Not sure I am comfortable with silent auto-creation of anything, let
alone users :-)
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Philip M. Gollucci wrote:
>> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
>> Moin and Confluence will be enough work as it is!
> Bugzilla integrates with LDAP already too and AD even (shudder).
Bugzilla integrates nicely with the mod_auth_* modules as well on a much
simpler level.
The modules are capable of exporting the user's name, email address, and
any other details you like into the environment, and bugzilla can pick
those details up from the environment, silently auto-creating the user
if necessary.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Philip M. Gollucci wrote:
> Upayavira wrote:
>>> On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
>>> Tony Stevenson wrote:
>>>
>>> A few people have helped start gathering requirements, and ideas here ->
>>>
>> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>>
>> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
>> Moin and Confluence will be enough work as it is!
> Bugzilla integrates with LDAP already too and AD even (shudder).
>
> I agree root@, sudo, and admin stuff can stay off this until its
> implemented. This is relatively trivial to add anyway with SSH keys and
> PAM (at least for the FBSD boxes) after LDAP is up and running. Even
> then its not really worth it for < 10 users/box.
>
> I saw kerberose was raised at one point. I know freebsd.org uses it
> cross country for FREEBSD.ORG, but I don't particularly like it in a
> mixed os environment.
>
Philip,
Why exactly don't you like Kerberos in a mixed OS platform? It is
extremely portable and cross platform friendly.
Also, let me state for the record, for everyone, we will not be using
LDAP for sudo. We dont need to cover this ground anymore :-)
Can we please all move on to discussing the scheme so we can at least
move to the next stage...
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Upayavira wrote:
>> On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
>> Tony Stevenson wrote:
>>
>> A few people have helped start gathering requirements, and ideas here ->
>>
> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
> Moin and Confluence will be enough work as it is!
Bugzilla integrates with LDAP already too and AD even (shudder).
I agree root@, sudo, and admin stuff can stay off this until its
implemented. This is relatively trivial to add anyway with SSH keys and
PAM (at least for the FBSD boxes) after LDAP is up and running. Even
then its not really worth it for < 10 users/box.
I saw kerberose was raised at one point. I know freebsd.org uses it
cross country for FREEBSD.ORG, but I don't particularly like it in a
mixed os environment.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior System Admin - RideCharge, Inc. http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
RE: Centralised authentication/authorisation
Posted by Gavin <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Upayavira [mailto:uv@odoko.co.uk]
> Sent: Tuesday, 25 November 2008 8:18 PM
> To: infrastructure-dev@apache.org
> Subject: Re: Centralised authentication/authorisation
>
> On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
> >
> > Tony Stevenson wrote:
> >
> > >
> > > A few people have helped start gathering requirements, and ideas here
> ->
> > >
> > > https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-
> project/
> > >
> >
> > I have just updated these a little.
> >
> >
> > Leading on from this, there are several steps that need to be
> > considered. This primarily revolves around the schema design, and which
> > product(s) should be considered.
> >
> > Does anyone have any ideas how you think the schema should look? There
> > is an initial document in the SVN repo.
> >
> > What about the concepts of using Kerberos and/or certificated?
>
> My one thought from browsing the proposed schema is that we have two use
> cases, committers and admins. Personally, at this point in time, I think
> we should be focussing on committers. That is where the scaling issues
> are. Adding Jack Black as root on hermes is a simple one off job that
> doesn't happen too often, so we can stick with our current scheme for
> the time being.
>
> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
> Moin and Confluence will be enough work as it is!
Confluence and Jira *shouldn't* be that hard. It already supports LDAP
either directly or via Crowd (Crowd delegates to LDAP/AD).
See :-
http://confluence.atlassian.com/display/DOC/Add+LDAP+Integration
and
http://www.atlassian.com/software/jira/docs/v3.13/ldap.html
However, I'd need to look at these more closely, the Jira LDAP method uses
their osuser method still in the latest Jira release, yet Confluence uses a
different 'atlassian-user' method and marks the 'osuser' method as
deprecated, so a conflict in terms of design I'd like to investigate more,
though I'm sure if each is individually configured wont pose a problem.
Personally, I'd like to see Crowd used for Confluence & Jira and then let
Crowd delegate to LDAP.
I'd go even further than that and suggest we apply for Jira Studio - which
combines Jira/Confluence/Fisheye/Crucible/Crowd (and Subversion) .
http://www.jira.com/tour/
The only ones out of that pack we don't use are Crowd and Crucible, Fisheye
some projects use off site.
Gav...(dons flack jacket)
>
> Upayavira
>
Re: Centralised authentication/authorisation
Posted by Upayavira <uv...@odoko.co.uk>.
On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
>
> Tony Stevenson wrote:
>
> >
> > A few people have helped start gathering requirements, and ideas here ->
> >
> > https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
> >
>
> I have just updated these a little.
>
>
> Leading on from this, there are several steps that need to be
> considered. This primarily revolves around the schema design, and which
> product(s) should be considered.
>
> Does anyone have any ideas how you think the schema should look? There
> is an initial document in the SVN repo.
>
> What about the concepts of using Kerberos and/or certificated?
My one thought from browsing the proposed schema is that we have two use
cases, committers and admins. Personally, at this point in time, I think
we should be focussing on committers. That is where the scaling issues
are. Adding Jack Black as root on hermes is a simple one off job that
doesn't happen too often, so we can stick with our current scheme for
the time being.
Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
Moin and Confluence will be enough work as it is!
Upayavira
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Henning Schmiedehausen wrote:
> On Sun, 2008-12-07 at 12:35 +0000, Tony Stevenson wrote:
>
>> 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.
>
> NO! WRONG! YOU DON'T MODIFY EXISTING OBJECT CLASSES!
>
> You add a new one, e.g. apachePerson which contains all the required
> fields. And you have your objects represent multiple object classes.
>
> This is a *basic* concept of LDAP. If you botch this, there is no point
> in using LDAP at all, because it will be unmanageable *very* quickly.
>
Sorry,
That is exactly what I meant. I just didn't say what I meant. By
butchered I did mean an extension of inetOrgPerson, incorporating all
the fields that we need.
By extension I mean, a new object class.
Whatever, I'll shut up now. Sleep, I need sleep.
Tony
Re: Centralised authentication/authorisation
Posted by Emmanuel Lécharny <el...@apache.org>.
Henning Schmiedehausen wrote:
>> It will likely we a butchered version of inetOrgPerson. Accomodating
>> many additional data fields.
>>
>
> NO! WRONG! YOU DON'T MODIFY EXISTING OBJECT CLASSES!
>
You just inherit from existing ObjectClasses :
( ObjectClass <apacheOCOID>
NAME 'ApacheOC'
DESC 'The ASF ObjectClass'
SUP 'InetOrgPerson'
MUST <all the added mandatory attributeTypes>
MAY <all the added optional attributeTypes>
)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Centralised authentication/authorisation
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Sun, 2008-12-07 at 12:35 +0000, Tony Stevenson wrote:
> 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.
NO! WRONG! YOU DON'T MODIFY EXISTING OBJECT CLASSES!
You add a new one, e.g. apachePerson which contains all the required
fields. And you have your objects represent multiple object classes.
This is a *basic* concept of LDAP. If you botch this, there is no point
in using LDAP at all, because it will be unmanageable *very* quickly.
Been there, got the T-Shirt.
Ciao
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux
Mail: henning@schmiedehausen.org -- Consultant, Architect, Developer
Web: http://henning.schmiedehausen.org/
Re: Centralised authentication/authorisation
Posted by Emmanuel Lécharny <el...@apache.org>.
Aristedes Maniatis wrote:
> <snip/>
>
>
>> 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. :-)
>
>
> If you'd like people to review it, please put the LDIF of your
> apachePerson up somewhere. I think getting that class right is 80% of
> the battle and the rest of the schema doesn't make much sense without it.
Here is a list of attributes we might need. This is just a first drop,
some attributes may be added.
ObjectClass ASF-person
----------------------
cn : the user common name
sn : the user surname
gn : the user given name
uid : the user id, the one the user connect with
asf-email+ : the ASF mail
asf-forward+ : the user .foward
mail* : any other user mail, may have more than one <im AT>*+ : The
Instant Messaging ids (to be defined, we may need more than one AT)
website*+ : the user website
asf-committer*+ : the projects the user is committer on (it's a ref)
asf-pmc+* : the PMC the user is member of (it's a ref)
asf-chairman+* : the projects the user is chairman of (it's a ref)
asf-board+ : tells if the user is a board member
asf-member+ : tells if the user is an asf member
asf-emeritus-committer+* : list the projects the user is emeritus
committer from
asf-emeritus-pmc+* : list the PMCs the user is emeritus for
asf-emeritus-member+ : tells if the user is an emeritus member
status : deceased or alive
company+* : gives the user's affiliation
blog+* : the user's blogs
asf-ccla: the ASF ccla, if any
asf-icla: the ASF icla
description : a shot notice about the user
l*: Localisation
c: The user's country
jpegPhoto*: The user's picture
usercertificate*: The user's certificates
pgp+: The user's PGP key-fingerprint
birthdate: The user's birthdate
age: The user's age
gender: Wether the user is male of female
asf-mentor+*: The list of incubator projects the user is mentor of
asf-moderator+*: The lists the user is currently moderating
example :
dn: uid=elecharny, ou=users, dc=apache, dc=org
uid: elecharny
cn: Emmanuel Lecharny
sn: Lecharny
gn: Emmanuel
asf-mail: elecharny@apache.org
mail: elecharny@iktek.com
mail: elecharny@hotmail.com
mail: elecharny@gmail.com
mail: elecharny@nextury.com
asf-forward : elecharny@iktek.com
im-jabber: elecharny@gmail.com
im-msn: elecharny@hotmail.com
im-yahoo: elecharny
web-site: www.iktek.com
web-site: www.newtury.com
asf-committer: cn=directory, ou=projects, dc=apache, dc=org
asf-committer: cn=mina, ou=projects, dc=apache, dc=org
asf-committer: cn=labs, ou=projects, dc=apache, dc=org
asf-committer: cn=incubator, ou=projects, dc=apache, dc=org
asf-pmc : cn=directory, ou=projects, dc=apache, dc=org
asf-pmc : cn=mina, ou=projects, dc=apache, dc=org
asf-pmc : cn=incubator, ou=projects, dc=apache, dc=org
asf-chairman : cn=directory, ou=projects, dc=apache, dc=org
asf-board: FALSE
asf-member: TRUE
asf-emeritus-member: FALSE
company: iktek
company: nextury
blog: http://hrabal.blogspot.com/
asf-icla: <the pdf>
description: nothing special
l: 101 rue saint-maur, 75011 Paris
c: France
jpegPhoto: <my picture>
usercertificate: ssh-dss
AAAAB3NzaC1kc3MAAACBAMUiQU0o3VlQddL0+vLiKFU0R5WvZTG78LrbOig+LlkzF0GKFGM6ls15xNu6FqC0o4pDFIpZMP+uWF04Y32qvfKhB1gEOHOWr7TOrk6FmRO8J2ocjhT+07ppTJIeKKsz6KPKLpZUY2GgL1xShakl8ewsVSQfhuL5+XmG3DnVg6FnAAAAFQDX7n7j5B2gth7AXtA27ksoEK8+NQAAAIEAujCU/hDFvFjX5mw2rv+J0prn01NKzrU+keV/XVDKZO/zrEe0DPYHFfXStwmZLSYpUyGxxqSRwUeRp/Ea9I614wkJ1DRryfPfeh7s91RP00SwkbZ9/v4O1/0FQZHgoWcXFkUyD1B8MqHCUTHraL2mi2BHGE11I+SSbPsh0bolu3sAAACAcG3uUgd5X6mfjt+HwXOhQwB7fHeQGjyUik3OYqMFKP/snB9ZHZQkrKDCi9Z5TL1mzDaN78sd8SqotacZX+YRst19g4dwxK/sLJ+c075a09bcRyMQVnvbNkitqiyRPee9sNr/W6qst5RDEegj7ffEujAZ4ituXMbyC/5In260fyc=
elecharny@elecharny-laptop
pgp: 104B FA7A 3C57 15C2 385E 563E 3CF3 921C C6D4 44ED
birthdate: 08/12/1964
age: 44
gender: male
asf-mentor: jsecurity
asf-moderator: commits@directory.apache.org
asf-moderator: dev@directory.apache.org
asf-moderator: users@directory.apache.org
asf-moderator: announce@directory.apache.org
asf-moderator: private@directory.apache.org
asf-moderator: commits@mina.apache.org
asf-moderator: dev@mina.apache.org
asf-moderator: users@mina.apache.org
asf-moderator: announce@mina.apache.org
asf-moderator: private@mina.apache.org
asf-moderator: jsecurity-dev@incubator.apache.org
asf-moderator: jsecurity-private@incubator.apache.org
asf-moderator: jsecurity-commits@incubator.apache.org
We should also be able to store some dates, like date when a user became
a committer on project X, and such.
ObjectClass ASF-project
cn: the project's name
asf-incubating+: Tells if the project is incubating
asf-inception+: The date of the project's inception
asf-tlp+: Tells if the project is a TLP or not
asf-project+: Gives the ref to the project this sub-project is depending
on (if the asf-tlp is FALSE and the asf-incubating is FALSE).
description: a short notice about the project
asf-website: The project's website
asf-irc+* : The associated IRC channels
asf-ml+*: The project mailing lists
asf-issues+*: The associated JIRA
asf-wiki+* : The associated wikis
asf-svn+ : The svn root
asf-status+ : Tells if the project is alive or dormant
asf-crypto+ : Tells if the project is using some cryptographic components
asf-release+* : Gives all the releases
dn: cn=directory, dc=projects, dc=apache, dc=org
cn: directory
asf-incubating: FALSE
asf-inception: 10 Sept 2003
asf-tlp: FALSE
description: The Apache Directory Project provides directory solutions
entirely written in Java.
These include a directory server, which has been certified as LDAP v3
compliant by the Open Group
(Apache Directory Server), and Eclipse-based directory tools (Apache
Directory Studio).
asf-website: http://directory.apache.org
asf-irc: #apache-directory
asf-irc: #apache-directory-dev
asf-ml: private@directory.apache.org
asf-ml: commits@directory.apache.org
asf-ml: users@directory.apache.org
asf-ml: announce@directory.apache.org
asf-issues: https://issues.apache.org/jira/browse/DIR
asf-issues: https://issues.apache.org/jira/browse/DIRSERVER
asf-wiki: http://cwiki.apache.org/confluence/display/directory
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxDEV
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxPMGT
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxSBOX
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxINTEROP
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxSRVx10
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxSRVx11
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxSRVx20
asf-wiki: http://cwiki.apache.org/confluence/display/DIRxSITE
asf-svn: https://svn.apache.org/repos/asf/directory
asf-status: alive
asf-crypto: TRUE
asf-release: 0.9.0
asf-release: 0.9.1
asf-release: 0.9.2
asf-release: 0.9.3
asf-release: 1.0-RC1
asf-release: 1.0-RC2
asf-release: 1.0-RC3
asf-release: 1.0-RC4
asf-release: 1.0.0
asf-release: 1.0.1
asf-release: 1.0.2
asf-release: 1.5.0
asf-release: 1.5.1
asf-release: 1.5.2
asf-release: 1.5.3
asf-release: 1.5.4
<note/>
>
> I don't understand what you mean by 'class of user' above. Do you mean
> class == objectClass in the LDAP sense?
I don't think that was what Tony meant. We will have different 'types'
of users : ASF committers, external contributors (like those who simply
fill a JIRA), etc.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Aristedes Maniatis wrote:
>
> On 07/12/2008, at 11:35 PM, Tony Stevenson wrote:
>
>>> * 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.
>
> I'm not following: openldap is available on pretty much every unix
> platform including Solaris.
>
I am led to believe in certain circumstances the Solaris native LDAP
client will not fully support OpenLDAP. We must insist on using the
native LDAP client so as to make sure it remains up-to-date, i.e.
security patches. I dont want to increase infra workload by having to
manually support/patch/fix LDAP clients on which ever servers we decide
to use this service.
Clearly this needs quantifying, but if it is remotely true clearly this
needs to be avoided.
This is why we will need to evaluate potential products, which so far
would appear to be:
ApacheDS
SolarisDS
OpenLDAP
>
>> 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. :-)
>
>
> If you'd like people to review it, please put the LDIF of your
> apachePerson up somewhere. I think getting that class right is 80% of
> the battle and the rest of the schema doesn't make much sense without it.
>
> I don't understand what you mean by 'class of user' above. Do you mean
> class == objectClass in the LDAP sense? If so, perhaps it is a mistake
> to change someone's DN four times just because they change status from
> third party, to committer, to board, and then resign back to third party
> again. LDAP has a strong sense of record identity and the best schemas
> I've seen tend not to require changing people's DN because of some third
> party event (like permissions).
No, that is not what I meant. I mean there ASF status. i.e. Are they a
committer, or a 3rd party person for example a buzilla/JIRA user.
A user's DN would remain static for as long as they are involved with
the ASF. Someone's DN would only change when they become a committer of
the ASF. In fact this would possibly mean the creation of a new object.
>
> Anyhow, I'm sure your ideas will become clearer when you post an updated
> version of the schema and apachePerson.
That's probably very true. I think I will use Emannuel's example of
apachePerson, and then tweak the directory schema to suit.
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
Re: Centralised authentication/authorisation
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 07/12/2008, at 11:35 PM, Tony Stevenson wrote:
>> * 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.
I'm not following: openldap is available on pretty much every unix
platform including Solaris.
> 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. :-)
If you'd like people to review it, please put the LDIF of your
apachePerson up somewhere. I think getting that class right is 80% of
the battle and the rest of the schema doesn't make much sense without
it.
I don't understand what you mean by 'class of user' above. Do you mean
class == objectClass in the LDAP sense? If so, perhaps it is a mistake
to change someone's DN four times just because they change status from
third party, to committer, to board, and then resign back to third
party again. LDAP has a strong sense of record identity and the best
schemas I've seen tend not to require changing people's DN because of
some third party event (like permissions).
Anyhow, I'm sure your ideas will become clearer when you post an
updated version of the schema and apachePerson.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 05/12/2008, at 12:02 PM, Tony Stevenson wrote:
>>> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>>>
>
> This tree is now "rw" for all committers.
> Please feel free to update the docs as they stand so far.
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:
* why has openldap been dismissed from consideration as a server? I'd
have thought it was one of the most used servers available?
* 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.
* what objectClasses are being used? Will people be inetOrgPerson or
posixUser or a custom apachePerson class which all the appropriate
attributes brought together?
* 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?
* 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.
Please excuse me if these things have been already discussed and
resolved before.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Tony Stevenson wrote:
>
>
> Tony Stevenson wrote:
>
>>
>> A few people have helped start gathering requirements, and ideas here ->
>>
>> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>>
>>
This tree is now "rw" for all committers.
Please feel free to update the docs as they stand so far.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
chris wrote:
>
> Throwing my hat in the ring to help with this however I can.
>
Excellent, that is four of us now.
Myself
Chris
Emmanuel
& Graham
Shall we proceed? If others wan't to join in they're more than welcome,
of course.
The overview so far:
* We (the ASF) need to use LDAP for centralised authenication
* LDAP (in whatever guise) needs to support multiple native LDAP clients
* We must have multi-site, and multi-master capabilities
* Initially we will only consider SVN & shell access to people.a.o as
goals
* Singular userid for all users in the ASF. Most likely their ASF
availid.
What we are not considering yet:
* Using LDAP with ther public services (JIRA, bugzilla, et al)
* Extending the OC any further, than required, to support goals above.
* Using LDAP for non-ASF users. i.e. public reporters of bugs via
Bugzilla.
So as I see it, we now need to agree on how we want to proceed. I
imagine agreeing on the structure OC for ASFPerson as a good a place as
any, then we can move on to how we want to organise the LDAP tree.
Again I am strongly in favour of keeping this as simple as possible.
I quite like emmanuel's previous ideas for the OC structure for
ASFPerson. Can we build on this?
What information do we want to store in this OC? I have placed an
example brief, copy of something taken from several emails to this list,
and shoved into the project folder in SVN.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by chris <ch...@ia.gov>.
> No, we are not going down the path of doing mod_sesion right now.
>
> Keep it simple, keep it bounded, get the core-services running, and skip
> on all this right now.
>
> -Paul
>
+1
Small initial scope. Keep it simple and remain flexible enough to deal with what may come where "what may come" is as
identified by the later phases of Tony's plan.
It is my understanding that this is to be a tool to make life easier for the Infrastructure team and that they have
identified these core services as being the best place to start. Some of the responses I have seen so far suggest
people thinking very big and far off, with grand ideas of the future. Wonderful stuff with great potential value. All
great ideas to be considered as we trot forward. For now though, do not lose sight of the primary goal of making things
easier to manage by turning this into something more complex than need be.
Throwing my hat in the ring to help with this however I can.
christopher rhodes
chris@ia.gov
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> Actually this is *exactly* the kind of behaviour I would expect. I don't
> see this as lame, at all, I see it is a standard way for
> browsers/a.n.other client to behave.
I haven't explained myself properly. Spot the flaw in the following flow:
- Enter your old password, and new password twice, click submit.
- Be told access has been denied. Enter your username, and then your new
password a third time, click submit.
The second step kicks in because the password has changed, but the
authnz mechanism doesn't know that and reports a sudden unexpected
authnz failure. The user ends up confused because they are being asked
to log in again from scratch, when they just entered their new password
- twice - moments before.
This is one of the key reasons basic authentication is considered so
user unfriendly, and why every web application out there has reinvented
login over and over again.
> I'm not sure we will be forced. Or at least I hope not. I am personally
> against SSO, as I see it is cruft, something that reduces security in
> this way makes me worry.
Can you explain how it reduces security in more detail?
> Prompting uers for their passwords for each service is not even on my
> radar, I don't think it is that much of an issue. They have to do it
> now, so when we introduce LDAP we won't set any expectation as to SSO
> services, i.e. they will still need to login to each service, but now
> with the same user/pass combo. This means they can change their
> password once, and be done with it.
I am all for making users lives easier. The users are the reason we are
doing all of this, after all.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Tony Stevenson wrote:
>
>> Exactly, at the moment users manage their shell passwords by logging
>> in and using the timeless 'passwd' command. :-)
>
> Yep, for those of us that know how, all is good, but for those of us who
> have to somehow figure out how putty works before they can do this, not
> so good. :)
In this case, I'd be worried why they were using a shell account in the
first place. But heck, that's just me. :-)
>
>> As for SVN passwords AISTR there is a web interface they can use to
>> reset this.
>>
>> So with this in mind, we will likely support both methods by the time
>> we are done. Though in what order/which guise is yet undecided. A
>> self managing system that allows users to reset their passwords is a
>> nice idea, and if we can sort this, it may go some way to alleviating
>> the pain nearer the times of en-masse logins (i.e. member votes)
>
> I have a solution for this that is ready to go, all it needs is to be
> installed. It does indeed solve much pain and annoyance for end users if
> there is one single canonical way to manage things like passwords.
>
>> Sorry Graham, set what up exactly? mod_session and sso?
>> At the moment we are not looking to rollout support for SSO (and by
>> SSO I mean the definition as it is in the "Scope & Goals" document in
>> SVN. (SVN:Infra\trunk\projects\ldap-project)
>
> The various apps that I have created to do the various bits and pieces
> like change passwords, reset forgotten passwords etc are built on top of
> mod_session. Just because these apps are built on top of mod_session
> does not mean that we are obligated to use mod_session for anything else
> just yet.
>
> Of course you aren't obligated to use mod_session with the apps, but if
> you don't, you get lame behaviour like being asked to suddenly re-log in
> directly after changing your password.
Actually this is *exactly* the kind of behaviour I would expect. I don't
see this as lame, at all, I see it is a standard way for
browsers/a.n.other client to behave.
>
>> Cool. We can always come and re-visit this as and when
>> time/desire/requirements allow us.
>
> I predict you will be forced to visit this sooner rather than later, but
> obviously only when you are ready. At the very least an LDAP server is
> required, and we don't have that yet.
I'm not sure we will be forced. Or at least I hope not. I am personally
against SSO, as I see it is cruft, something that reduces security in
this way makes me worry.
Prompting uers for their passwords for each service is not even on my
radar, I don't think it is that much of an issue. They have to do it
now, so when we introduce LDAP we won't set any expectation as to SSO
services, i.e. they will still need to login to each service, but now
with the same user/pass combo. This means they can change their
password once, and be done with it.
That's just my opinion mind you, YMMV.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> Exactly, at the moment users manage their shell passwords by logging in
> and using the timeless 'passwd' command. :-)
Yep, for those of us that know how, all is good, but for those of us who
have to somehow figure out how putty works before they can do this, not
so good. :)
> As for SVN passwords AISTR there is a web interface they can use to
> reset this.
>
> So with this in mind, we will likely support both methods by the time we
> are done. Though in what order/which guise is yet undecided. A self
> managing system that allows users to reset their passwords is a nice
> idea, and if we can sort this, it may go some way to alleviating the
> pain nearer the times of en-masse logins (i.e. member votes)
I have a solution for this that is ready to go, all it needs is to be
installed. It does indeed solve much pain and annoyance for end users if
there is one single canonical way to manage things like passwords.
> Sorry Graham, set what up exactly? mod_session and sso?
> At the moment we are not looking to rollout support for SSO (and by SSO
> I mean the definition as it is in the "Scope & Goals" document in SVN.
> (SVN:Infra\trunk\projects\ldap-project)
The various apps that I have created to do the various bits and pieces
like change passwords, reset forgotten passwords etc are built on top of
mod_session. Just because these apps are built on top of mod_session
does not mean that we are obligated to use mod_session for anything else
just yet.
Of course you aren't obligated to use mod_session with the apps, but if
you don't, you get lame behaviour like being asked to suddenly re-log in
directly after changing your password.
> Cool. We can always come and re-visit this as and when
> time/desire/requirements allow us.
I predict you will be forced to visit this sooner rather than later, but
obviously only when you are ready. At the very least an LDAP server is
required, and we don't have that yet.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Tony Stevenson wrote:
>
>>> What is your definition of "core-services"?
>>
>> As stated a few times the basic we want to support, intially at least,
>> are SVN and shell access to people.a.o
>
> Fair enough.
>
> Let me explain better where I am coming from. When you have an LDAP
> server, you inherit a support burden, which is completely independent of
> what you want to use the LDAP server for.
>
> Key things are how the data ends up in the LDAP server in the first
> place, how people are able to manage their passwords without the schlepp
> of having to log into p.a.o and use a protocol they may or may not be
> familiar with.
Exactly, at the moment users manage their shell passwords by logging in
and using the timeless 'passwd' command. :-)
As for SVN passwords AISTR there is a web interface they can use to
reset this.
So with this in mind, we will likely support both methods by the time we
are done. Though in what order/which guise is yet undecided. A self
managing system that allows users to reset their passwords is a nice
idea, and if we can sort this, it may go some way to alleviating the
pain nearer the times of en-masse logins (i.e. member votes)
>
> I have spent a good 18 months solving this particular problem, with a
> combination of additional features to httpd, and some small web based
> apps that were designed for this purpose. What I am offering is that I
> set up this up for you, and in the process potentially remove the
> problems of password management and distribution, and other future
> problems such as new user account creation.
Sorry Graham, set what up exactly? mod_session and sso?
At the moment we are not looking to rollout support for SSO (and by SSO
I mean the definition as it is in the "Scope & Goals" document in SVN.
(SVN:Infra\trunk\projects\ldap-project)
> No, we don't have to set this up right now.
>
> I am however throwing this suggestion into the ring now, so that people
> are aware this work exists, and in an effort to ensure no wheels are
> reinvented unnecessarily.
Cool. We can always come and re-visit this as and when
time/desire/requirements allow us.
>
>> Anything other than that will fall into a following phase of the
>> deployment. I don't think we could sustain a big-bang cut over to LDAP
>> for all public services from day 1.
>
> Obviously, I was not proposing any kind of big bang cutover of anything.
> Any cutover should happen in a leisurely controlled fashion, as people
> are comfortable with doing so, and as confidence grows in the stability
> of the service.
Cool. :-)
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
>> What is your definition of "core-services"?
>
> As stated a few times the basic we want to support, intially at least,
> are SVN and shell access to people.a.o
Fair enough.
Let me explain better where I am coming from. When you have an LDAP
server, you inherit a support burden, which is completely independent of
what you want to use the LDAP server for.
Key things are how the data ends up in the LDAP server in the first
place, how people are able to manage their passwords without the schlepp
of having to log into p.a.o and use a protocol they may or may not be
familiar with.
I have spent a good 18 months solving this particular problem, with a
combination of additional features to httpd, and some small web based
apps that were designed for this purpose. What I am offering is that I
set up this up for you, and in the process potentially remove the
problems of password management and distribution, and other future
problems such as new user account creation.
No, we don't have to set this up right now.
I am however throwing this suggestion into the ring now, so that people
are aware this work exists, and in an effort to ensure no wheels are
reinvented unnecessarily.
> Anything other than that will fall into a following phase of the
> deployment. I don't think we could sustain a big-bang cut over to LDAP
> for all public services from day 1.
Obviously, I was not proposing any kind of big bang cutover of anything.
Any cutover should happen in a leisurely controlled fashion, as people
are comfortable with doing so, and as confidence grows in the stability
of the service.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Paul Querna wrote:
>
>> No, we are not going down the path of doing mod_sesion right now.
>>
>> Keep it simple, keep it bounded, get the core-services running, and
>> skip on all this right now.
>
> What is your definition of "core-services"?
As stated a few times the basic we want to support, intially at least,
are SVN and shell access to people.a.o
Anything other than that will fall into a following phase of the
deployment. I don't think we could sustain a big-bang cut over to LDAP
for all public services from day 1.
So moving in other services after the fact will also allow us to learn
how best to achieve such moves without it blowing up in our faces.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> No, we are not going down the path of doing mod_sesion right now.
>
> Keep it simple, keep it bounded, get the core-services running, and skip
> on all this right now.
What is your definition of "core-services"?
I have found from experience that most apps out there already work
really well with normal CGI environment variables, or basic auth headers
handed to them from Apache. And it turns out that httpd is really good
at providing those header and variables to underlying apps, on condition
the user is authnz to httpd.
Trying to configure apps like bugzilla and friends to access LDAP
directly is doing this the hard way.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Paul Querna <pq...@apache.org>.
Graham Leggett wrote:
> Tony Stevenson wrote:
>
>> Cool, but we have not yet agreed upon what we are going to be working
>> towards. That comes next :-)
>
> I would argue that agreeing what we are working towards would come first :)
>
>> Exactly, and even when it does (possibly) exist there is still no need
>> for authentication, AFAICS.
>
> We use authnz across the ASF, from bugzilla, to jira, to various
> continuous integration servers. Facing a similar problem myself (many
> apps, in different architectures, all trying to maintain their own
> authnz databases, and with inconsistent support for LDAP), it prompted
> me to introduce mod_session and mod_auth_form to httpd, and have httpd
> worry about authnz, and have the underlying apps take for granted that
> authnz has already happened.
No, we are not going down the path of doing mod_sesion right now.
Keep it simple, keep it bounded, get the core-services running, and skip
on all this right now.
-Paul
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> Cool, but we have not yet agreed upon what we are going to be working
> towards. That comes next :-)
I would argue that agreeing what we are working towards would come first :)
> Exactly, and even when it does (possibly) exist there is still no need
> for authentication, AFAICS.
We use authnz across the ASF, from bugzilla, to jira, to various
continuous integration servers. Facing a similar problem myself (many
apps, in different architectures, all trying to maintain their own
authnz databases, and with inconsistent support for LDAP), it prompted
me to introduce mod_session and mod_auth_form to httpd, and have httpd
worry about authnz, and have the underlying apps take for granted that
authnz has already happened.
While I could wave my hands in the air and try to explain it, it is far
easier for me to just deploy a test version of it to show people.
Consider it as the very first user of the LDAP service. :)
>> At this point we have the danger of just talking about it for ages and
>> ages, and never getting anything done.
>
> if we talk about it now, and then someone chimes up just after
> deployment that they wanted it do x,y, and z, we can tell them that they
> had their opportunity to take part on this ML.
One important thing: any LDAP infrastructure will be a living breathing
thing. Requirements will change over time, and people will chime in with
suggestions for how the LDAP database could be extended or improved.
No part of the design should be "closed" or "cast in stone", and at no
point should anybody be told "you had your opportunity to take part but
you didn't".
>> Let's start by getting a basic server running, and populate it with
>> some basic information, not accessible to the public.
>
> That won't happen until we all agree on all the fundamental basics
> first. There is absolutely no hurry to get this done. I was pushing on
> ahead with this, much like you seem to want too, but it wont help us.
> Not in the long run.
People aren't willing to pipe up with objections until they have
something concrete to object to.
From what I can see, the basics are pretty covered:
- We need a server, and we have one in the form of ADS.
- We need a basic schema, and considering the desire is just authnz at
this point, the schemas that already exist should do nicely.
Is there anything else we need to cover?
> I will be one of those admins. I'm not sure any requirement exists from
> those of us that will administer this, to have it do anything other that
> access control.
Having spoken to a number of people in the long time during which the
LDAP ball has been kicked around at the ASF, there is definitely a
desire to store more than just access control in LDAP.
While I as you do see no need to do this now, we certainly do not want
to close any doors or make it more difficult to do this in future.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Tony Stevenson wrote:
>
>> Graham we have not yet agreed, i.e. have had written in stone, what we
>> will and will not support. Plus I am not sure what https://www.a.o has
>> to do with LDAP.
>
> It has to do with single signon, which is based on LDAP, and is one of
> the most fundamental ways in which an LDAP server makes our lives easier.
Cool, but we have not yet agreed upon what we are going to be working
towards. That comes next :-)
>
>> AFAIK there is no authentication required when browsing that site.
>
> The site doesn't yet exist (ie connection refused).
Exactly, and even when it does (possibly) exist there is still no need
for authentication, AFAICS.
>
>> I think there is one other person who is willing to help us. I just
>> want him to announce himself. Rather than being 'outed' by me. :-)
>>
>> I think once we have 4 people, we can consider the next steps.
>>
>> * What we want to achieve from LDAP
>> * How we want to deploy it
>> * etc
>
> At this point we have the danger of just talking about it for ages and
> ages, and never getting anything done.
if we talk about it now, and then someone chimes up just after
deployment that they wanted it do x,y, and z, we can tell them that they
had their opportunity to take part on this ML.
> Let's start by getting a basic server running, and populate it with some
> basic information, not accessible to the public.
That won't happen until we all agree on all the fundamental basics
first. There is absolutely no hurry to get this done. I was pushing on
ahead with this, much like you seem to want too, but it wont help us.
Not in the long run.
>
> It is far easier to show people what LDAP is, and what single singon is,
> rather than trying to explain it in a handwaving fashion.
We only have to prove it works to other folks in Infra, the rest of the
community who will use it as a service probably dont care that we use
LDAP or not.
These said folks in infra already know what LDAP is, how it works
(fundamentally), and are aware of the bells and whistles it can come with.
>
> I think we have established already what we want to achieve by using
> LDAP: to make our lives easier.
Yes, maybe. But we will not get any traction until we have a solid base
upon which we can build a working solution. For that we need to have
* A working group of folks to run with it
* Agreed on goals (see updated SVN docs)
>
> Any LDAP infrastructure is going to change with time. We will find new
> requirements, we will need to keep the admin people who have to care and
> feed this thing happy, and people will keep asking "wouldn't it be cool
> if...".
>
I will be one of those admins. I'm not sure any requirement exists from
those of us that will administer this, to have it do anything other that
access control.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> Graham we have not yet agreed, i.e. have had written in stone, what we
> will and will not support. Plus I am not sure what https://www.a.o has
> to do with LDAP.
It has to do with single signon, which is based on LDAP, and is one of
the most fundamental ways in which an LDAP server makes our lives easier.
> AFAIK there is no authentication required when
> browsing that site.
The site doesn't yet exist (ie connection refused).
> I think there is one other person who is willing to help us. I just want
> him to announce himself. Rather than being 'outed' by me. :-)
>
> I think once we have 4 people, we can consider the next steps.
>
> * What we want to achieve from LDAP
> * How we want to deploy it
> * etc
At this point we have the danger of just talking about it for ages and
ages, and never getting anything done.
Let's start by getting a basic server running, and populate it with some
basic information, not accessible to the public.
It is far easier to show people what LDAP is, and what single singon is,
rather than trying to explain it in a handwaving fashion.
I think we have established already what we want to achieve by using
LDAP: to make our lives easier.
Any LDAP infrastructure is going to change with time. We will find new
requirements, we will need to keep the admin people who have to care and
feed this thing happy, and people will keep asking "wouldn't it be cool
if...".
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Emmanuel Lécharny wrote:
> Graham Leggett wrote:
>> Tony Stevenson wrote:
>>
>>> So, who wants to come up to the table and volunteer to help drag the
>>> ASF into the 1990's of authentication? :-)
>>
>> I volunteer to configure and set up https://www.apache.org, and
>> volunteer to configure the single signon stuff present in httpd
>> v2.3.0+, in readiness for being backed by an LDAP server.
> I'm in, too. I can try first to define a basic schema, and migrate our
> current users into a LDAP server.
>>
Ok, so we have 3 folks so far.
Emmanuel
Graham
and myself.
Let's not start carving up the work just yet. :-)
Graham we have not yet agreed, i.e. have had written in stone, what we
will and will not support. Plus I am not sure what https://www.a.o has
to do with LDAP. AFAIK there is no authentication required when
browsing that site.
I think there is one other person who is willing to help us. I just want
him to announce himself. Rather than being 'outed' by me. :-)
I think once we have 4 people, we can consider the next steps.
* What we want to achieve from LDAP
* How we want to deploy it
* etc
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Emmanuel Lécharny <el...@apache.org>.
Tony Stevenson wrote:
>
> As I say, I want to prevent this from becoming the mother of all
> databases. So for now let's keep it simple. I am not sure if we want
> to move .forward files into LDAP just yet, think of the number of
> directory lookups when email committers@ for example.
Last time I did some perf tests on ADS, random searches into a 10K users
for a specific indexed attribute, I was able to load my poor centrino
duo 2Ghz laptop and get back around 5000 req/s... We did the same test
with Alex (random searches) on a 8 way cpus, with 5 millions entries,
and get 13 000 req/s handled smoothly (the server wasn't eating more
than 60% CPU). And with OpenLdap, you can get twice those numbers ...
So the number of requests we will have is, IMHO, not a real pb atm.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Centralised authentication/authorisation
Posted by Emmanuel Lécharny <el...@apache.org>.
Tony Stevenson wrote:
>
>
> Graham Leggett wrote:
>> Emmanuel Lécharny wrote:
>
> [SNIP ...]
>
>>
>> If we start with just the following, we could build up from there:
>>
>> objectClass: top
>> objectClass: person
>> objectClass: inetOrgPerson
>> objectClass: mailRecipient
>> objectClass: organizationalPerson
>>
>> Next step after that, add some ASF attributes where relevant:
>>
>> objectclass: asfPerson
>> objectclass: asfCommitter
>> objectclass: asfMember
>>
>> etc
>
> As I say, I want to prevent this from becoming the mother of all
> databases. So for now let's keep it simple. I am not sure if we want
> to move .forward files into LDAP just yet, think of the number of
> directory lookups when email committers@ for example.
The beauty of LDAP is that you can add some new attributes to our own
AsfPerson ObjectClass (I will use OC and AT for respectively ObjectClass
and AttributeType in the following mials, 'coz I'm lazzy ...) without
having to change the existing entries, except if we add some new MUST AT.
So nothing forbid us to start simple, and little by little improve the
AsfPerson OC.
I'm not very found of the multiple OC proposed by Graham (ie,
AsfCommitter, AsfMember), but if needed, we can discuss this aspect (me
not being found of does not mean I'm correct on that ...)
I suggest we start with what Graham needs atm.
>
>
> Cheeers,
> Tony
>
>
>
>
> -----------------------------------------
> 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
> -----------------------------------------
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> As I say, I want to prevent this from becoming the mother of all
> databases. So for now let's keep it simple. I am not sure if we want to
> move .forward files into LDAP just yet, think of the number of directory
> lookups when email committers@ for example.
Lets not get ahead of ourselves - the objectclasses list a large number
of optional attributes, and they are all just that: optional.
The objectclasses listed above exist and are widely supported out there.
We must definitely avoid reinventing the wheel if we can possibly
avoid it.
LDAP databases are designed to hold millions of users in them, handling
the equivalent of .forward files is very unlikely to cause a typical
LDAP server to break a sweat. We can worry about this sort of thing
later, which we should focus on at this point is to ensure we don't need
to refactor our data down the line.
Here is a simple example entry that I use in production, with email:
dn: mail=foo@bar,ou=People,ou=Foo,o=Bar,c=UK
givenName: Foo
sn: Bar
mailAlternateAddress: treasurer@bar
mail: foo@bar
mailForwardingAddress: foo@baz
uid: foo
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: mailRecipient
objectClass: organizationalPerson
mailHost: mailserver.domain.com
mailDeliveryOption: mailbox
cn: Foo Bar
And without:
dn: mail=foo@example.com,ou=People,ou=Foo,o=Bar,c=UK
givenName: Foo
sn: Bar
mail: foo@example.com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: Foo Bar
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Graham Leggett wrote:
> Emmanuel Lécharny wrote:
[SNIP ...]
>
> If we start with just the following, we could build up from there:
>
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: mailRecipient
> objectClass: organizationalPerson
>
> Next step after that, add some ASF attributes where relevant:
>
> objectclass: asfPerson
> objectclass: asfCommitter
> objectclass: asfMember
>
> etc
As I say, I want to prevent this from becoming the mother of all
databases. So for now let's keep it simple. I am not sure if we want to
move .forward files into LDAP just yet, think of the number of directory
lookups when email committers@ for example.
Cheeers,
Tony
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Emmanuel Lécharny wrote:
>> I volunteer to configure and set up https://www.apache.org, and
>> volunteer to configure the single signon stuff present in httpd
>> v2.3.0+, in readiness for being backed by an LDAP server.
> I'm in, too. I can try first to define a basic schema, and migrate our
> current users into a LDAP server.
The only attributes I need at this point to make this happen are a
userid (email address highly recommended), and password.
One thing we need to be careful of to keep our lives simple is to make
sure our schema doesn't clash with any other schemas out there.
I have been using the 50ns-mail.ldif schema from Fedora Directory
Server, most specifically the mail, mailAlternateAddress and
mailForwardingAddress attributes.
Users that are "external" have their external email address (used as
their login name) stored in the "mail" attribute.
Users that have hosted mail have a mailRecipient objectclass, and any
mail aliases go into mailAlternateAddress. Users who want mail
forwarding use mailForwardingAddress.
If we use an objectclass such as 50ns-mail.ldif, we leave the door open
to have email backed by LDAP in a reasonably straightforward fashion.
If we start with just the following, we could build up from there:
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: mailRecipient
objectClass: organizationalPerson
Next step after that, add some ASF attributes where relevant:
objectclass: asfPerson
objectclass: asfCommitter
objectclass: asfMember
etc
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Emmanuel Lécharny <el...@apache.org>.
Graham Leggett wrote:
> Tony Stevenson wrote:
>
>> So, who wants to come up to the table and volunteer to help drag the
>> ASF into the 1990's of authentication? :-)
>
> I volunteer to configure and set up https://www.apache.org, and
> volunteer to configure the single signon stuff present in httpd
> v2.3.0+, in readiness for being backed by an LDAP server.
I'm in, too. I can try first to define a basic schema, and migrate our
current users into a LDAP server.
>
> Regards,
> Graham
> --
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Centralised authentication/authorisation
Posted by Graham Leggett <mi...@sharp.fm>.
Tony Stevenson wrote:
> So, who wants to come up to the table and volunteer to help drag the ASF
> into the 1990's of authentication? :-)
I volunteer to configure and set up https://www.apache.org, and
volunteer to configure the single signon stuff present in httpd v2.3.0+,
in readiness for being backed by an LDAP server.
Regards,
Graham
--
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Tony Stevenson wrote:
>
> I have just updated these a little.
I have now updated them again, following this email thread,
conversations on IRC and in emails with other folks.
I would like to see a few folks step forward and volunteer to shepard
through a small part of the who project, to try and get more eyes on the
work that needs to be done, but also so more people can have some input
as to how LDAP will be shaped.
I believe that LDAP is the way forward for the ASF to manage
authentication & authorisation for public services. As such I think we
should steer clear of using it to store every possible attribute
possible about a person. It should remain a database for access control,
and not a database full of bloat.
So, who wants to come up to the table and volunteer to help drag the ASF
into the 1990's of authentication? :-)
Some ideas of how we can split the work, or rather into what sections
are also welcome. i.e. desisn, testing, documenting, implementation, etc
Once we have a list of folks, and how we think we could divvy up the
work we can proceed.
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------
Re: Centralised authentication/authorisation
Posted by Tony Stevenson <pc...@apache.org>.
Tony Stevenson wrote:
>
> A few people have helped start gathering requirements, and ideas here ->
>
> https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>
I have just updated these a little.
Leading on from this, there are several steps that need to be
considered. This primarily revolves around the schema design, and which
product(s) should be considered.
Does anyone have any ideas how you think the schema should look? There
is an initial document in the SVN repo.
What about the concepts of using Kerberos and/or certificated?
Cheers,
Tony
--
-----------------------------------------
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
-----------------------------------------