Re: Single Sign On for Debian

[Xavier]

Le 22/08/2017 à 18:51, Xavier a écrit :
> Le 22/08/2017 à 16:29, gregor herrmann a écrit :
>> On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote:
>>
 There is lemonldap-ng already packaged which provides saml, oauth,
 openid-connect, CAS, and more (both identity provider and service
 provider). It works with users in ldap but doesn't have a user management
 interface.

 We use it at work and it integrates nicely with all kind of webapp
 (including gitlab, via oauth).
>>> I haven't looked into it. Can lemonldap-ng have multiple backends at the 
>>> same
>>> time? 
>>> Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?
>>
>> I haven't used lemonldap-ng but I'd like to add that it's maintained
>> in Debian by Xavier Guimard (within the Debian Perl Group) who's also
>> part of upstream. I'm sure he's happy to help by answering questions
>> and maybe also setup or changes etc. (CC'd).
> 
> Hi all,
> 
> LLNG can have many backends simultaneously. The 2.0 version (not yet
> published, in tests) adds a better plugin system that can be used to
> create new backends. For now, LLNG is usable with:
> * LDAP, Active-Directory, SQL, Kerberos (better with 2.0), Radius,
>   another LLNG system (proxy or delegate), SSL (using webserver),
>   Yubikey (better with 2.0), WebID,
> * SAML-2.0, CAS, OpenID-2.0, OpenID-Connect,
> * Multi   : backend chosed by rule (better with 2.0 => "Combination")
> * Choice  : user can choose its backend
> * backends usable by 2.0 only:
>   * PAM
>   * REST API
>   * Second factor (U2F or custom)
> 
> It can also (and simultaneously) be used as identity provider for CAS,
> OpenID-Connect, OpenID-2.0, SAML
> 
> It has been designed for French government but is used in many places
> now. Our main installation handles hundreds applications for ~25
> users (~30 millions hits/day). I've heard about a bigger one in US but
> have no info on it.
> 
> Best regards,
> Xavier
> 
> https://lemonldap-ng.org

Hi all,

lemonldap-ng 2.0 has been released (soon in Debian unstable). There are
many new features that can be useful.

Cheers,
Xavier
---
https://lemonldap-ng.org/documentation/latest/start
https://fusioniam.org

Re: Single Sign On for Debian

[Benoit Mortier]

Le 25/08/2017 à 16:48, Luca Filipozzi a écrit :
> On Fri, Aug 25, 2017 at 10:39:14AM +0200, Clément OUDOT wrote:
>> 2017-08-25 6:59 GMT+02:00 Luca Filipozzi :
>>> On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
 Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
> On Wed, 23 Aug 2017, Philip Hands wrote:
>
>> Michael Lustfield  writes:
>>
>> ...
>>> Using Gitlab (or any VCS) as the user db for guest accounts means 
>>> adding a
>>> dependency that could block future upgrades... kinda like now. This is 
>>> not a
>>> future-proof design and will come at a future cost.
>>
>> I suspect that Alexander's intent was just to avoid blocking the gitlab
>> setup on having some SSO solution in place.
>>
>> If lemonldap-ng can make use of gitlab's guest data initially, then that
>> lets the two things be setup independently.
>>
>> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
>> to transfer authority for the guest data into lemonldap-ng's control,
>> and then have gitlab use lemonldap-ng as it's source of that data.
> I dont' think Lemonldap-ng does usermanagement on its own.
> It is a replacement for sso.d.o which allows to have more backends and
> provides more frontends (like saml, oauth2 and so on)
>
> Alex

 You're right, LLNG doesn't provide usermanagement. Many user's use
 https://lsc-project.org to populate a LDAP directory from any source.
 Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
 You can ping him if you have any question on this
>>>
>>> LDAP sync isn't what is meant by 'user management'. Rather, it's a
>>> combination of self-empowerment (create account, manage profile, reset
>>> password) and delegation administration (role creation and assignment,
>>> etc.). Keycloak offers some of this functionality. Whatsay I stand up a
>>> demo and we can kick some tires?
>>
>> Keycloack might be a good solution. I suggest you also test
>> FusionDirectory which I often use with LemonLDAP::NG to provide a full
>> identity management solution : https://www.fusiondirectory.org/
> 
> I'll have a look and consider standing it up adjacent to keycloak so we
> can kick the tires of both.
> 
>> I made a presentation about some free softwares products that can be
>> used together for identity management :
>> https://www.slideshare.net/coudot/rmll2017-des-logiciels-libres-pour-la-gestion-des-identits.
>> Sadly it's in french but you have all product names, screenshots and
>> links to websites.
> 
> Merci.
> 
>> For information there will be a lot of presentation on this topic at
>> the next LDAPCon (https://ldapcon.org/2017/). Maybe some people from
>> Debian community can join us at this event.
> 
> I can't but maybe other DSA members can. I mention DSA in particular
> because I personally view the management of LDAP and Identity Provider
> Solutions as fairly core duties of DSA. I have to build consensus with
> my colleagues (so start with a public email, Luca, that's a good idea)
> but the demo is as much for them as for anyone else. (hi guys)

hello,

as the organisator of LDAPcon 2017, we can also make special prices for
Debian DSA guys if they want to come as we are heavy debian users here.

Cheers
-- 
Benoit Mortier
CEO
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.org/



signature.asc
Description: OpenPGP digital signature

Re: Single Sign On for Debian

[Benoit Mortier]

Le 25/08/2017 à 10:39, Clément OUDOT a écrit :
> 2017-08-25 6:59 GMT+02:00 Luca Filipozzi :
>> On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
>>> Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
 On Wed, 23 Aug 2017, Philip Hands wrote:

> Michael Lustfield  writes:
>
> ...
>> Using Gitlab (or any VCS) as the user db for guest accounts means adding 
>> a
>> dependency that could block future upgrades... kinda like now. This is 
>> not a
>> future-proof design and will come at a future cost.
>
> I suspect that Alexander's intent was just to avoid blocking the gitlab
> setup on having some SSO solution in place.
>
> If lemonldap-ng can make use of gitlab's guest data initially, then that
> lets the two things be setup independently.
>
> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
> to transfer authority for the guest data into lemonldap-ng's control,
> and then have gitlab use lemonldap-ng as it's source of that data.
 I dont' think Lemonldap-ng does usermanagement on its own.
 It is a replacement for sso.d.o which allows to have more backends and
 provides more frontends (like saml, oauth2 and so on)

 Alex
>>>
>>> You're right, LLNG doesn't provide usermanagement. Many user's use
>>> https://lsc-project.org to populate a LDAP directory from any source.
>>> Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
>>> You can ping him if you have any question on this
>>
>> LDAP sync isn't what is meant by 'user management'. Rather, it's a
>> combination of self-empowerment (create account, manage profile, reset
>> password) and delegation administration (role creation and assignment,
>> etc.). Keycloak offers some of this functionality. Whatsay I stand up a
>> demo and we can kick some tires?
> 
> Keycloack might be a good solution. I suggest you also test
> FusionDirectory which I often use with LemonLDAP::NG to provide a full
> identity management solution : https://www.fusiondirectory.org/
> 
> I made a presentation about some free softwares products that can be
> used together for identity management :
> https://www.slideshare.net/coudot/rmll2017-des-logiciels-libres-pour-la-gestion-des-identits.
> Sadly it's in french but you have all product names, screenshots and
> links to websites.

Hello,

are some slides in english about FusionDirectory and the possibility,
real users cases in english

https://www.slideshare.net/benoitmortier/one-year-solving-infrastructure-management-with-fusiondirectory-and-openldap

https://www.slideshare.net/benoitmortier/improving-the-ow2-infrastructure-with-fusiondirectory

Feel free to talk to me directly if you have any questions

> For information there will be a lot of presentation on this topic at
> the next LDAPCon (https://ldapcon.org/2017/). Maybe some people from
> Debian community can join us at this event.

Cheers
-- 
Benoit Mortier
CEO
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.org/



signature.asc
Description: OpenPGP digital signature

Re: Single Sign On for Debian

[Luca Filipozzi]

On Fri, Aug 25, 2017 at 10:39:14AM +0200, Clément OUDOT wrote:
> 2017-08-25 6:59 GMT+02:00 Luca Filipozzi :
> > On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
> >> Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
> >> > On Wed, 23 Aug 2017, Philip Hands wrote:
> >> >
> >> >> Michael Lustfield  writes:
> >> >>
> >> >> ...
> >> >>> Using Gitlab (or any VCS) as the user db for guest accounts means 
> >> >>> adding a
> >> >>> dependency that could block future upgrades... kinda like now. This is 
> >> >>> not a
> >> >>> future-proof design and will come at a future cost.
> >> >>
> >> >> I suspect that Alexander's intent was just to avoid blocking the gitlab
> >> >> setup on having some SSO solution in place.
> >> >>
> >> >> If lemonldap-ng can make use of gitlab's guest data initially, then that
> >> >> lets the two things be setup independently.
> >> >>
> >> >> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
> >> >> to transfer authority for the guest data into lemonldap-ng's control,
> >> >> and then have gitlab use lemonldap-ng as it's source of that data.
> >> > I dont' think Lemonldap-ng does usermanagement on its own.
> >> > It is a replacement for sso.d.o which allows to have more backends and
> >> > provides more frontends (like saml, oauth2 and so on)
> >> >
> >> > Alex
> >>
> >> You're right, LLNG doesn't provide usermanagement. Many user's use
> >> https://lsc-project.org to populate a LDAP directory from any source.
> >> Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
> >> You can ping him if you have any question on this
> >
> > LDAP sync isn't what is meant by 'user management'. Rather, it's a
> > combination of self-empowerment (create account, manage profile, reset
> > password) and delegation administration (role creation and assignment,
> > etc.). Keycloak offers some of this functionality. Whatsay I stand up a
> > demo and we can kick some tires?
> 
> Keycloack might be a good solution. I suggest you also test
> FusionDirectory which I often use with LemonLDAP::NG to provide a full
> identity management solution : https://www.fusiondirectory.org/

I'll have a look and consider standing it up adjacent to keycloak so we
can kick the tires of both.

> I made a presentation about some free softwares products that can be
> used together for identity management :
> https://www.slideshare.net/coudot/rmll2017-des-logiciels-libres-pour-la-gestion-des-identits.
> Sadly it's in french but you have all product names, screenshots and
> links to websites.

Merci.

> For information there will be a lot of presentation on this topic at
> the next LDAPCon (https://ldapcon.org/2017/). Maybe some people from
> Debian community can join us at this event.

I can't but maybe other DSA members can. I mention DSA in particular
because I personally view the management of LDAP and Identity Provider
Solutions as fairly core duties of DSA. I have to build consensus with
my colleagues (so start with a public email, Luca, that's a good idea)
but the demo is as much for them as for anyone else. (hi guys)

-- 
Luca Filipozzi

Re: Single Sign On for Debian

[Clément OUDOT]

2017-08-25 6:59 GMT+02:00 Luca Filipozzi :
> On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
>> Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
>> > On Wed, 23 Aug 2017, Philip Hands wrote:
>> >
>> >> Michael Lustfield  writes:
>> >>
>> >> ...
>> >>> Using Gitlab (or any VCS) as the user db for guest accounts means adding 
>> >>> a
>> >>> dependency that could block future upgrades... kinda like now. This is 
>> >>> not a
>> >>> future-proof design and will come at a future cost.
>> >>
>> >> I suspect that Alexander's intent was just to avoid blocking the gitlab
>> >> setup on having some SSO solution in place.
>> >>
>> >> If lemonldap-ng can make use of gitlab's guest data initially, then that
>> >> lets the two things be setup independently.
>> >>
>> >> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
>> >> to transfer authority for the guest data into lemonldap-ng's control,
>> >> and then have gitlab use lemonldap-ng as it's source of that data.
>> > I dont' think Lemonldap-ng does usermanagement on its own.
>> > It is a replacement for sso.d.o which allows to have more backends and
>> > provides more frontends (like saml, oauth2 and so on)
>> >
>> > Alex
>>
>> You're right, LLNG doesn't provide usermanagement. Many user's use
>> https://lsc-project.org to populate a LDAP directory from any source.
>> Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
>> You can ping him if you have any question on this
>
> LDAP sync isn't what is meant by 'user management'. Rather, it's a
> combination of self-empowerment (create account, manage profile, reset
> password) and delegation administration (role creation and assignment,
> etc.). Keycloak offers some of this functionality. Whatsay I stand up a
> demo and we can kick some tires?

Keycloack might be a good solution. I suggest you also test
FusionDirectory which I often use with LemonLDAP::NG to provide a full
identity management solution : https://www.fusiondirectory.org/

I made a presentation about some free softwares products that can be
used together for identity management :
https://www.slideshare.net/coudot/rmll2017-des-logiciels-libres-pour-la-gestion-des-identits.
Sadly it's in french but you have all product names, screenshots and
links to websites.

For information there will be a lot of presentation on this topic at
the next LDAPCon (https://ldapcon.org/2017/). Maybe some people from
Debian community can join us at this event.

Clément Oudot.

Re: Single Sign On for Debian

[Alexander Wirt]

On Fri, 25 Aug 2017, Luca Filipozzi wrote:

> On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
> > Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
> > > On Wed, 23 Aug 2017, Philip Hands wrote:
> > > 
> > >> Michael Lustfield  writes:
> > >>
> > >> ...
> > >>> Using Gitlab (or any VCS) as the user db for guest accounts means 
> > >>> adding a
> > >>> dependency that could block future upgrades... kinda like now. This is 
> > >>> not a
> > >>> future-proof design and will come at a future cost.
> > >>
> > >> I suspect that Alexander's intent was just to avoid blocking the gitlab
> > >> setup on having some SSO solution in place.
> > >>
> > >> If lemonldap-ng can make use of gitlab's guest data initially, then that
> > >> lets the two things be setup independently.
> > >>
> > >> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
> > >> to transfer authority for the guest data into lemonldap-ng's control,
> > >> and then have gitlab use lemonldap-ng as it's source of that data.
> > > I dont' think Lemonldap-ng does usermanagement on its own. 
> > > It is a replacement for sso.d.o which allows to have more backends and
> > > provides more frontends (like saml, oauth2 and so on)
> > > 
> > > Alex
> > 
> > You're right, LLNG doesn't provide usermanagement. Many user's use
> > https://lsc-project.org to populate a LDAP directory from any source.
> > Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
> > You can ping him if you have any question on this
> 
> LDAP sync isn't what is meant by 'user management'. Rather, it's a
> combination of self-empowerment (create account, manage profile, reset
> password) and delegation administration (role creation and assignment,
> etc.). Keycloak offers some of this functionality. Whatsay I stand up a
> demo and we can kick some tires?
Role and Group Management can probably be delegated to the application. But
the self-empowerment is the important thing. A demo would indeed be nice. 

Alex

Re: Single Sign On for Debian

[Luca Filipozzi]

On Wed, Aug 23, 2017 at 09:05:32AM +0200, Xavier wrote:
> Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
> > On Wed, 23 Aug 2017, Philip Hands wrote:
> > 
> >> Michael Lustfield  writes:
> >>
> >> ...
> >>> Using Gitlab (or any VCS) as the user db for guest accounts means adding a
> >>> dependency that could block future upgrades... kinda like now. This is 
> >>> not a
> >>> future-proof design and will come at a future cost.
> >>
> >> I suspect that Alexander's intent was just to avoid blocking the gitlab
> >> setup on having some SSO solution in place.
> >>
> >> If lemonldap-ng can make use of gitlab's guest data initially, then that
> >> lets the two things be setup independently.
> >>
> >> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
> >> to transfer authority for the guest data into lemonldap-ng's control,
> >> and then have gitlab use lemonldap-ng as it's source of that data.
> > I dont' think Lemonldap-ng does usermanagement on its own. 
> > It is a replacement for sso.d.o which allows to have more backends and
> > provides more frontends (like saml, oauth2 and so on)
> > 
> > Alex
> 
> You're right, LLNG doesn't provide usermanagement. Many user's use
> https://lsc-project.org to populate a LDAP directory from any source.
> Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
> You can ping him if you have any question on this

LDAP sync isn't what is meant by 'user management'. Rather, it's a
combination of self-empowerment (create account, manage profile, reset
password) and delegation administration (role creation and assignment,
etc.). Keycloak offers some of this functionality. Whatsay I stand up a
demo and we can kick some tires?

-- 
Luca Filipozzi

Re: Single Sign On for Debian

[Xavier]

Le 23/08/2017 à 08:46, Alexander Wirt a écrit :
> On Wed, 23 Aug 2017, Philip Hands wrote:
> 
>> Michael Lustfield  writes:
>>
>> ...
>>> Using Gitlab (or any VCS) as the user db for guest accounts means adding a
>>> dependency that could block future upgrades... kinda like now. This is not a
>>> future-proof design and will come at a future cost.
>>
>> I suspect that Alexander's intent was just to avoid blocking the gitlab
>> setup on having some SSO solution in place.
>>
>> If lemonldap-ng can make use of gitlab's guest data initially, then that
>> lets the two things be setup independently.
>>
>> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
>> to transfer authority for the guest data into lemonldap-ng's control,
>> and then have gitlab use lemonldap-ng as it's source of that data.
> I dont' think Lemonldap-ng does usermanagement on its own. 
> It is a replacement for sso.d.o which allows to have more backends and
> provides more frontends (like saml, oauth2 and so on)
> 
> Alex

You're right, LLNG doesn't provide usermanagement. Many user's use
https://lsc-project.org to populate a LDAP directory from any source.
Clément Oudot (leader of LLNG community) is also leader of LSC-Project.
You can ping him if you have any question on this



signature.asc
Description: OpenPGP digital signature

Re: Single Sign On for Debian

[Alexander Wirt]

On Wed, 23 Aug 2017, Philip Hands wrote:

> Michael Lustfield  writes:
> 
> ...
> > Using Gitlab (or any VCS) as the user db for guest accounts means adding a
> > dependency that could block future upgrades... kinda like now. This is not a
> > future-proof design and will come at a future cost.
> 
> I suspect that Alexander's intent was just to avoid blocking the gitlab
> setup on having some SSO solution in place.
> 
> If lemonldap-ng can make use of gitlab's guest data initially, then that
> lets the two things be setup independently.
> 
> Once lemonldap-ng is shown to do the job, I doubt it will be a big task
> to transfer authority for the guest data into lemonldap-ng's control,
> and then have gitlab use lemonldap-ng as it's source of that data.
I dont' think Lemonldap-ng does usermanagement on its own. 
It is a replacement for sso.d.o which allows to have more backends and
provides more frontends (like saml, oauth2 and so on)


Alex



signature.asc
Description: PGP signature

Re: Single Sign On for Debian

[Philip Hands]

Michael Lustfield  writes:

...
> Using Gitlab (or any VCS) as the user db for guest accounts means adding a
> dependency that could block future upgrades... kinda like now. This is not a
> future-proof design and will come at a future cost.

I suspect that Alexander's intent was just to avoid blocking the gitlab
setup on having some SSO solution in place.

If lemonldap-ng can make use of gitlab's guest data initially, then that
lets the two things be setup independently.

Once lemonldap-ng is shown to do the job, I doubt it will be a big task
to transfer authority for the guest data into lemonldap-ng's control,
and then have gitlab use lemonldap-ng as it's source of that data.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Single Sign On for Debian

[Michael Lustfield]

On Tue, 22 Aug 2017 18:10:39 +0200
Geert Stappers  wrote:

> On Tue, Aug 22, 2017 at 04:29:49PM +0200, gregor herrmann wrote:
> > On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote:
> >   
> > > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?
> > [...]
> [...]

This seems like backward thinking to me.

> Thing that I hope is that Alioth successors will have the various services
> on separate machines. So that we have not again the situation when replacing
> a Source Code Management system we also have to replace the machine
> with all the -guest accounts.

I whole heartedly agree! One of the current challenges with replacing Alioth is
because of how many services it's providing. If Alioth were not being used for
guest accounts, this wouldn't even be a discussion.

Using Gitlab (or any VCS) as the user db for guest accounts means adding a
dependency that could block future upgrades... kinda like now. This is not a
future-proof design and will come at a future cost.

I'm happy to help implement an SSO solution that Gitlab is capable of using,
but I argue against using Gitlab as a future user database.


Side note... I got cert-based SSO working on https://gitea.debian.net/. It
actually ended up being pretty easy and kinda fun. I have a ticket with
upstream to support populating the email address, but that'll be a while.

Cheers,
-- 
Michael Lustfield

Re: Single Sign On for Debian

[Xavier]

Le 22/08/2017 à 16:29, gregor herrmann a écrit :
> On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote:
> 
>>> There is lemonldap-ng already packaged which provides saml, oauth,
>>> openid-connect, CAS, and more (both identity provider and service
>>> provider). It works with users in ldap but doesn't have a user management
>>> interface.
>>>
>>> We use it at work and it integrates nicely with all kind of webapp
>>> (including gitlab, via oauth).
>> I haven't looked into it. Can lemonldap-ng have multiple backends at the same
>> time? 
>> Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?
> 
> I haven't used lemonldap-ng but I'd like to add that it's maintained
> in Debian by Xavier Guimard (within the Debian Perl Group) who's also
> part of upstream. I'm sure he's happy to help by answering questions
> and maybe also setup or changes etc. (CC'd).

Hi all,

LLNG can have many backends simultaneously. The 2.0 version (not yet
published, in tests) adds a better plugin system that can be used to
create new backends. For now, LLNG is usable with:
* LDAP, Active-Directory, SQL, Kerberos (better with 2.0), Radius,
  another LLNG system (proxy or delegate), SSL (using webserver),
  Yubikey (better with 2.0), WebID,
* SAML-2.0, CAS, OpenID-2.0, OpenID-Connect,
* Multi   : backend chosed by rule (better with 2.0 => "Combination")
* Choice  : user can choose its backend
* backends usable by 2.0 only:
  * PAM
  * REST API
  * Second factor (U2F or custom)

It can also (and simultaneously) be used as identity provider for CAS,
OpenID-Connect, OpenID-2.0, SAML

It has been designed for French government but is used in many places
now. Our main installation handles hundreds applications for ~25
users (~30 millions hits/day). I've heard about a bigger one in US but
have no info on it.

Best regards,
Xavier

https://lemonldap-ng.org



signature.asc
Description: OpenPGP digital signature

Re: Single Sign On for Debian

[Geert Stappers]

On Tue, Aug 22, 2017 at 04:29:49PM +0200, gregor herrmann wrote:
> On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote:
> 
> > > There is lemonldap-ng already packaged which provides saml, oauth,
> > > openid-connect, CAS, and more (both identity provider and service
> > > provider). It works with users in ldap but doesn't have a user management
> > > interface.
> > > 
> > > We use it at work and it integrates nicely with all kind of webapp
> > > (including gitlab, via oauth).
> > I haven't looked into it. Can lemonldap-ng have multiple backends at the 
> > same
> > time? 
> > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?
> 
> I haven't used lemonldap-ng but I'd like to add that it's maintained
> in Debian by Xavier Guimard (within the Debian Perl Group) who's also
> part of upstream. I'm sure he's happy to help by answering questions
> and maybe also setup or changes etc. (CC'd).
> 

URL for clicking https://lemonldap-ng.org/welcome/

On Tue, Aug 22, 2017 at 09:30:50AM +0200, Philipp Hug wrote:
> On Aug 22, 2017 8:23 AM, "Luca Filipozzi"  wrote:
>
> > Has anyone looked at Keycloak? http://www.keycloak.org/
>
> I have and deployed it for others in production. Not an unreasonable
> option.
>
>
> I'm running it in production as well. If you need some help to
> evaluate/configure it, just ping me.
 

What I learned from the Alioth Sprint last weekend
is that DSA previously handed-out a new (test) machine easily.
New policy is handing-out machines for the stage after early tests.


Thing that I hope is that Alioth successors will have the various services
on separate machines. So that we have not again the situation when replacing
a Source Code Management system we also have to replace the machine
with all the -guest accounts.


Don't count on me for that. New tasks I volunteert for during
the Alioth replacement sprint are  listmaster and http://gitea.debian.net
maintenance. So most likely nothing new:  We all agree that someone else
should do it. And we all respect those who actually do.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Single Sign On for Debian

[gregor herrmann]

On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote:

> > There is lemonldap-ng already packaged which provides saml, oauth,
> > openid-connect, CAS, and more (both identity provider and service
> > provider). It works with users in ldap but doesn't have a user management
> > interface.
> > 
> > We use it at work and it integrates nicely with all kind of webapp
> > (including gitlab, via oauth).
> I haven't looked into it. Can lemonldap-ng have multiple backends at the same
> time? 
> Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?

I haven't used lemonldap-ng but I'd like to add that it's maintained
in Debian by Xavier Guimard (within the Debian Perl Group) who's also
part of upstream. I'm sure he's happy to help by answering questions
and maybe also setup or changes etc. (CC'd).

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Oscar Brown Jr.: Brother Where Are You?


signature.asc
Description: Digital Signature

Re: Single Sign On for Debian

[Alexander Wirt]

On Tue, 22 Aug 2017, Mathieu Parent wrote:

> Hello,
> 
> Le mardi 22 août 2017, Luca Filipozzi  a écrit :
> > On Mon, Aug 21, 2017 at 04:35:59PM -0700, Raoul Snyman wrote:
> >> On 2017-08-21 5:48, Alexander Wirt wrote:
> >> > > I second that: Using LDAP as a single source of truth. It's also
> >> > > possible to store SSH keys etc. in LDAP.
> >> > Then someone has to go ahead and develop a complete usermangement for
> >> > sso.d.o. As it is we can't work with software that is maybe coming at
> >> > some
> >> > point. Therefore we will start with gitlabs own user management,
> >> > combined
> >> > with debians ldap.
> >> >
> >> > But if you do take in point the following things:
> >> >
> >> > - user self management (lost password, deletion)
> >> > - key self management
> >> > - api for user manipulation
> >> > - oauth2 frontend (sso as oauth2 provider)
> >> > - maybe saml frontend (sso as saml provider)
> >>
> >> Has anyone looked at Keycloak? http://www.keycloak.org/
> >
> > I have and deployed it for others in production. Not an unreasonable
> > option.
> 
> There is lemonldap-ng already packaged which provides saml, oauth,
> openid-connect, CAS, and more (both identity provider and service
> provider). It works with users in ldap but doesn't have a user management
> interface.
> 
> We use it at work and it integrates nicely with all kind of webapp
> (including gitlab, via oauth).
I haven't looked into it. Can lemonldap-ng have multiple backends at the same
time? 
Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend?

If the answer is yes, I maybe find time to evaluate it (of course any help is
appreciated)

Alex

Re: Single Sign On for Debian

[Philipp Hug]

On Aug 22, 2017 8:23 AM, "Luca Filipozzi"  wrote:

> Has anyone looked at Keycloak? http://www.keycloak.org/

I have and deployed it for others in production. Not an unreasonable
option.


I'm running it in production as well. If you need some help to
evaluate/configure it, just ping me.

Philipp

Re: Single Sign On for Debian

[Mathieu Parent]

Hello,

Le mardi 22 août 2017, Luca Filipozzi  a écrit :
> On Mon, Aug 21, 2017 at 04:35:59PM -0700, Raoul Snyman wrote:
>> On 2017-08-21 5:48, Alexander Wirt wrote:
>> > > I second that: Using LDAP as a single source of truth. It's also
>> > > possible to store SSH keys etc. in LDAP.
>> > Then someone has to go ahead and develop a complete usermangement for
>> > sso.d.o. As it is we can't work with software that is maybe coming at
>> > some
>> > point. Therefore we will start with gitlabs own user management,
>> > combined
>> > with debians ldap.
>> >
>> > But if you do take in point the following things:
>> >
>> > - user self management (lost password, deletion)
>> > - key self management
>> > - api for user manipulation
>> > - oauth2 frontend (sso as oauth2 provider)
>> > - maybe saml frontend (sso as saml provider)
>>
>> Has anyone looked at Keycloak? http://www.keycloak.org/
>
> I have and deployed it for others in production. Not an unreasonable
> option.

There is lemonldap-ng already packaged which provides saml, oauth,
openid-connect, CAS, and more (both identity provider and service
provider). It works with users in ldap but doesn't have a user management
interface.

We use it at work and it integrates nicely with all kind of webapp
(including gitlab, via oauth).

Regards

Mathieu Parent



-- 
Mathieu

Re: Single Sign On for Debian

[Luca Filipozzi]

On Mon, Aug 21, 2017 at 04:35:59PM -0700, Raoul Snyman wrote:
> On 2017-08-21 5:48, Alexander Wirt wrote:
> > > I second that: Using LDAP as a single source of truth. It's also
> > > possible to store SSH keys etc. in LDAP.
> > Then someone has to go ahead and develop a complete usermangement for
> > sso.d.o. As it is we can't work with software that is maybe coming at
> > some
> > point. Therefore we will start with gitlabs own user management,
> > combined
> > with debians ldap.
> > 
> > But if you do take in point the following things:
> > 
> > - user self management (lost password, deletion)
> > - key self management
> > - api for user manipulation
> > - oauth2 frontend (sso as oauth2 provider)
> > - maybe saml frontend (sso as saml provider)
> 
> Has anyone looked at Keycloak? http://www.keycloak.org/

I have and deployed it for others in production. Not an unreasonable
option.

-- 
Luca Filipozzi

Re: Single Sign On for Debian

[Raoul Snyman]

On 2017-08-21 5:48, Alexander Wirt wrote:

I second that: Using LDAP as a single source of truth. It's also
possible to store SSH keys etc. in LDAP.

Then someone has to go ahead and develop a complete usermangement for
sso.d.o. As it is we can't work with software that is maybe coming at 
some
point. Therefore we will start with gitlabs own user management, 
combined

with debians ldap.

But if you do take in point the following things:

- user self management (lost password, deletion)
- key self management
- api for user manipulation
- oauth2 frontend (sso as oauth2 provider)
- maybe saml frontend (sso as saml provider)

Alex



Has anyone looked at Keycloak? http://www.keycloak.org/


--
Raoul Snyman
+1 (520) 490-9743
ra...@snyman.info

Re: Single Sign On for Debian

[Alexander Wirt]

On Mon, 21 Aug 2017, Georg Faerber wrote:

> On 17-08-21 11:18:05, Enrico Zini wrote:
> > On Sun, Aug 20, 2017 at 04:28:05PM +, Luca Filipozzi wrote:
> > 
> > > As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two
> > > related but orthogonal things:
> > > 1 collapsing user management into a single user store (LDAP)**
> > 
> > I really, really like the idea of having all the accounts in a single
> > LDAP, regardless of the SSO system used.
> > 
> > +1 to that!
> 
> I second that: Using LDAP as a single source of truth. It's also
> possible to store SSH keys etc. in LDAP.
Then someone has to go ahead and develop a complete usermangement for
sso.d.o. As it is we can't work with software that is maybe coming at some
point. Therefore we will start with gitlabs own user management, combined
with debians ldap.

But if you do take in point the following things:

- user self management (lost password, deletion)
- key self management
- api for user manipulation
- oauth2 frontend (sso as oauth2 provider)
- maybe saml frontend (sso as saml provider)

Alex



signature.asc
Description: PGP signature

Re: Single Sign On for Debian

[Georg Faerber]

On 17-08-21 11:18:05, Enrico Zini wrote:
> On Sun, Aug 20, 2017 at 04:28:05PM +, Luca Filipozzi wrote:
> 
> > As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two
> > related but orthogonal things:
> > 1 collapsing user management into a single user store (LDAP)**
> 
> I really, really like the idea of having all the accounts in a single
> LDAP, regardless of the SSO system used.
> 
> +1 to that!

I second that: Using LDAP as a single source of truth. It's also
possible to store SSH keys etc. in LDAP.

Cheers,
Georg


signature.asc
Description: Digital signature

Re: Single Sign On for Debian

[Holger Levsen]

On Sun, Aug 20, 2017 at 06:16:07PM +0200, Geert Stappers wrote:
> - Forwarded message from Enrico Zini <enr...@debian.org> -
> > SSO, as it is right now, is NOT a user managing thing. SSO is ONLY
> > taking existing users from one or more (two right now, db.d.o/alioth)
> > backends, and allows them to have a single sign on on connected debian
> > services, nm.debian.org being the biggest of it, DebConf pages the next
> > one (that i know of).

tracker.debian.org is another big user of SSO (and is ment to replace
packages.qa.d.o.)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Single Sign On for Debian

[Enrico Zini]

On Sun, Aug 20, 2017 at 04:28:05PM +, Luca Filipozzi wrote:

> As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two
> related but orthogonal things:
> 1 collapsing user management into a single user store (LDAP)**

I really, really like the idea of having all the accounts in a single
LDAP, regardless of the SSO system used.

+1 to that!


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Single Sign On for Debian

[Marcin Kulisz]

On 2017-08-20 16:28:05, Luca Filipozzi wrote:
> As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two
> related but orthogonal things:
> 1 collapsing user management into a single user store (LDAP)**
> 2 introducing SAML or OIDC IdPs so that we can tie into AWS, Azure, and
>   GCP SSO features
> 
> 1 isn't necessarily a pre-requisite for 2 but the mishmash of processing
> we have Guest vs DM vs DD is fugly (let alone Alioth-type users).

Looking at the above from Cloud Team member perspective I'd like to see this
done. I also know that JEB was suggesting something similar some time ago.
I don't think that any of the Cloud Team members or DDs would be against this
solution, but if they would is it should be know, that's why cross post to
debian-cloud (sorry for this) so people can vice their opinion.

At this point in time I'm not capable of helping with backends but I could
help with integrating db.d.o with our AWS account (I'm one of the admins)
however we'll choose to do it.

From experience I also know that not too many non DD or DMs are having access to
those (AWS,GCP) accounts. So focusing on those 2 groups should be sufficient
for start.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Re: Single Sign On for Debian

[Luca Filipozzi]

On Sun, Aug 20, 2017 at 06:16:07PM +0200, Geert Stappers wrote:
> 
> Previous on mailinglist
> alioth-staff-replacem...@lists.alioth.debian.org
> 
> IMHO is debian-devel@lists.debian.org a better place for this.
> 
> 
> - Forwarded message from Enrico Zini <enr...@debian.org> -
> 
> Date: Sun, 20 Aug 2017 18:03:26 +0200 From: Enrico Zini
> <enr...@debian.org> To:
> alioth-staff-replacem...@lists.alioth.debian.org Cc: Geert Stappers
> <stapp...@stappers.nl> Subject: Re: [Alioth-staff-replacement] Fwd:
> Re:  Alioth needs your help User-Agent: NeoMutt/20170113 (1.7.2)
> 
> > >> SSO doesn't have own backends.
> > > Isn't  db.debian.org the backend that knowns about all DD?
> > 
> > SSO, as it is right now, is NOT a user managing thing. SSO is ONLY
> > taking existing users from one or more (two right now,
> > db.d.o/alioth) backends, and allows them to have a single sign on on
> > connected debian services, nm.debian.org being the biggest of it,
> > DebConf pages the next one (that i know of).
> > 
> > If someone is willing to invest the time and work to make SSO fly up
> > and be THE one point other things can connect to, meaning that it
> > eats DD data from db.d.o but does its own user management for
> > non-DDs, and also willing to maintain that over time - and then also
> > add stuff like being an ouath provider, SAML something, whatever
> > those things are called by now, so that applications/services can
> > easily be connected to it - then setups like gitlab/gitea/whatever
> > can go and use it as a provider, and not the other way round.
> > 
> > I am pretty sure the current maintainers of sso would love to get
> > help, possibly to the point of being happy to entirely give it to
> > someone who really wants to invest the time and work, also i cant
> > speak for them, so talk to them for more.
> 
> Hi there. I'm not on this list, keep me Cc-ed or add me to the list as
> you wish.
> 
> I am currently the only maintainer of sso.d.o and I confirm what
> Ganneff said.
> 
> Currently not only sso.d.o doesn't do any user database, but it also
> never sees the users' web password or alioth passwords. Authentication
> is delegated to apache's mod_ldap, and I just see what's in
> REMOTE_USER.  A bug in my code, with the current setup, won't leak
> users' passwords no matter what.
> 
> I'm happy to give up maintenance of sso.d.o entirely and I don't mind
> if it gets replaced with whatever makes sense. The current setup is
> the simplest and most secure setup I can think of that can be
> maintained by one person, relies on widespread and well tested code
> (except for the custom certificate generation interface) and can
> federate trivially.
> 
> Note that it's security-sensitive code for which I don't even get code
> review of my commits, with the exception of some recent post-debconf
> review and feedback by paultag. 
> 
> However, if anyone takes sso.d.o over, and then at some point
> disappears, I will be the most affected, as a broken sso.debian.org
> means a broken nm.debian.org and contributors.debian.org and I am the
> person taking care for those, too. In fact, I got stuck with
> maintaining sso.debian.org because the other people involved pulled
> out and I needed to keep nm.debian.org running, so that scenario has
> happened before.  If it happens again, depending on what
> sso.debian.org will have become, I might choose to take down
> nm.debian.org until someone else fixes sso.debian.org, instead of
> taking ownership of something I can't maintain.
> 
> I understand that gitlab has its own user database / registration /
> password change infrastructure; if you want to use that, we can see
> how to make sso.debian.org authenticate to it.
> 
> If instead you prefer to have sso.debian.org handle non-DD
> registration, it is doable: python3-django-registration exists and can
> be used, and gitlab can probably then consume the client certificates.
> 
> Between the two options, I would imagine that the gitlab registration
> code is far more polished and well tested than
> python3-django-registration, so I would suggest to have people
> register on gitlab and then interface sso.debian.org with that.

As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two
related but orthogonal things:
1 collapsing user management into a single user store (LDAP)**
2 introducing SAML or OIDC IdPs so that we can tie into AWS, Azure, and
  GCP SSO features

1 isn't necessarily a pre-requisite for 2 but the mishmash of processing
we have Guest vs DM vs DD is fugly (let alone Alioth-type users).

** Not necessarily the opinion of all DSA team members.

-- 
Luca Filipozzi

Single Sign On for Debian

[Geert Stappers]

Previous on mailinglist alioth-staff-replacem...@lists.alioth.debian.org

IMHO is debian-devel@lists.debian.org a better place for this.


- Forwarded message from Enrico Zini <enr...@debian.org> -

Date: Sun, 20 Aug 2017 18:03:26 +0200
From: Enrico Zini <enr...@debian.org>
To: alioth-staff-replacem...@lists.alioth.debian.org
Cc: Geert Stappers <stapp...@stappers.nl>
Subject: Re: [Alioth-staff-replacement] Fwd: Re:  Alioth needs your help
User-Agent: NeoMutt/20170113 (1.7.2)

> >> SSO doesn't have own backends.
> > Isn't  db.debian.org the backend that knowns about all DD?
> 
> SSO, as it is right now, is NOT a user managing thing. SSO is ONLY
> taking existing users from one or more (two right now, db.d.o/alioth)
> backends, and allows them to have a single sign on on connected debian
> services, nm.debian.org being the biggest of it, DebConf pages the next
> one (that i know of).
> 
> If someone is willing to invest the time and work to make SSO fly up and
> be THE one point other things can connect to, meaning that it eats DD
> data from db.d.o but does its own user management for non-DDs, and also
> willing to maintain that over time - and then also add stuff like being
> an ouath provider, SAML something, whatever those things are called by
> now, so that applications/services can easily be connected to it - then
> setups like gitlab/gitea/whatever can go and use it as a provider, and
> not the other way round.
> 
> I am pretty sure the current maintainers of sso would love to get help,
> possibly to the point of being happy to entirely give it to someone who
> really wants to invest the time and work, also i cant speak for them, so
> talk to them for more.

Hi there. I'm not on this list, keep me Cc-ed or add me to the list as
you wish.

I am currently the only maintainer of sso.d.o and I confirm what Ganneff
said.

Currently not only sso.d.o doesn't do any user database, but it also
never sees the users' web password or alioth passwords. Authentication
is delegated to apache's mod_ldap, and I just see what's in REMOTE_USER.
A bug in my code, with the current setup, won't leak users' passwords no
matter what.

I'm happy to give up maintenance of sso.d.o entirely and I don't mind if
it gets replaced with whatever makes sense. The current setup is the
simplest and most secure setup I can think of that can be maintained by
one person, relies on widespread and well tested code (except for the
custom certificate generation interface) and can federate trivially.

Note that it's security-sensitive code for which I don't even get code
review of my commits, with the exception of some recent post-debconf
review and feedback by paultag. 

However, if anyone takes sso.d.o over, and then at some point
disappears, I will be the most affected, as a broken sso.debian.org
means a broken nm.debian.org and contributors.debian.org and I am the
person taking care for those, too. In fact, I got stuck with maintaining
sso.debian.org because the other people involved pulled out and I needed
to keep nm.debian.org running, so that scenario has happened before.
If it happens again, depending on what sso.debian.org will have become,
I might choose to take down nm.debian.org until someone else fixes
sso.debian.org, instead of taking ownership of something I can't
maintain.

I understand that gitlab has its own user database / registration /
password change infrastructure; if you want to use that, we can see how
to make sso.debian.org authenticate to it.

If instead you prefer to have sso.debian.org handle non-DD registration,
it is doable: python3-django-registration exists and can be used, and
gitlab can probably then consume the client certificates.

Between the two options, I would imagine that the gitlab registration
code is far more polished and well tested than
python3-django-registration, so I would suggest to have people register
on gitlab and then interface sso.debian.org with that.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>



___
Alioth-staff-replacement mailing list
alioth-staff-replacem...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/alioth-staff-replacement


- End forwarded message -

-- 
Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature