> "Peter" == Peter Palfrader writes:
Peter> On Mon, 13 Apr 2020, Sam Hartman wrote:
>> > "Luca" == Luca Filipozzi writes:
>>
Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca>
On Mon, 13 Apr 2020, Sam Hartman wrote:
> > "Luca" == Luca Filipozzi writes:
>
> Luca> This is why having a central approach to account creation,
> Luca> rather than distributed, is worth considering. I'm in favour
> Luca> of usernames not changing because one's role changes but
On Mon, Apr 13, 2020 at 6:39 pm, Tollef Fog Heen wrote:
It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your
primary
goal? That's my most immediate concern. Switching to oauth2/OIDC
seems
like a good idea,
]] Enrico Zini
> On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:
>
> > We quite regularly have upstreams getting access for weird architecture
> > failures. There's no particular reason for those people to have salsa
> > accounts.
>
> I understand those are temporary accounts.
> "Luca" == Luca Filipozzi writes:
Luca> This is why having a central approach to account creation,
Luca> rather than distributed, is worth considering. I'm in favour
Luca> of usernames not changing because one's role changes but that
Luca> does not mean I'm favour of divergen
On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:
> We quite regularly have upstreams getting access for weird architecture
> failures. There's no particular reason for those people to have salsa
> accounts.
I understand those are temporary accounts. Do those cases need an
arbitra
On Sun, Apr 12, 2020 at 08:21:49AM +0300, Andrei POPESCU wrote:
> On Sb, 11 apr 20, 19:27:53, Julien Cristau wrote:
> > On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> > >
> > > I must be missing something so I'm asking: what is the *benefit* of
> > > avoiding collisions with De
]] Sam Hartman
> > "Tollef" == Tollef Fog Heen writes:
>
> Tollef> ]] Enrico Zini
> >> For guest accounts opened by DSA directly, it can be pretty much
>
> First, at this point in time I would be very skepticle of someone
> contributing to Debian enough to need porter box access bu
On Sb, 11 apr 20, 19:27:53, Julien Cristau wrote:
> On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> >
> > I must be missing something so I'm asking: what is the *benefit* of
> > avoiding collisions with Debian accounts?
> >
> f...@salsa.debian.org and f...@debian.org both exist
> "Michael" == Michael Lustfield writes:
Michael> Multiple concerns have been raised and subsequently
Michael> shrugged off. It's clear that no concern raised will make
Michael> any difference so, yeah... go for it.
Actually, Enrico provided a summary describing how the concerns
> "Julien" == Julien Cristau writes:
Julien> On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
>>
Julien> f...@salsa.debian.org and f...@debian.org both existing and
Julien> referring to different people risks causing confusion. I'd
Julien> like to understa
On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote:
> On Mi, 08 apr 20, 19:40:27, Julien Cristau wrote:
> > On Wed, Apr 8, 2020 at 14:30:43 +0200, Bastian Blank wrote:
> >
> > > Hi Zhu
> > >
> > > On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > > > 1. Can you still
On Sat, 11 Apr 2020 12:02:40 +0200
Jonathan Carter wrote:
> [...]
> This thread has had lots of discussion so far and no one has listed a
> single reason against your proposal yet, IMHO if no one is standing in
> your way it's time to just go ahead and do it.
Multiple concerns have been raised a
On 2020/04/10 13:05, Felix Lechner wrote:
> As a group, we are driving Enrico up the wall. Let's just get rid of
> the old stuff now
...
+1
Enrico, your plans sound very sane and from all the information in these
threads it seems logical for the project to go ahead with it.
What's holding you ba
On Mi, 08 apr 20, 19:40:27, Julien Cristau wrote:
> On Wed, Apr 8, 2020 at 14:30:43 +0200, Bastian Blank wrote:
>
> > Hi Zhu
> >
> > On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > > recognize who is D
On 10 April 2020 12:05:42 BST, Felix Lechner wrote:
>Hi,
>
>As a group, we are driving Enrico up the wall. Let's just get rid of
>the old stuff now and have a discussion about keycloak and
>lemonldap-ng at the same time.
I fully support this statement also please remember that perfect is the ene
Luca Filipozzi writes:
> I think that our services -- such as SCM, CI/CD, Wiki, RT, etc. --
> should evolve indepdently from the SSO infrastructure. One could argue
> that RT has a user database thatcould be used as authenticaion service
> if exposed correctly. Or the Wiki.
Let me try to rephase
On Fri, Apr 10, 2020 at 02:08:01PM -0400, Sam Hartman wrote:
> > "Russ" == Russ Allbery writes:
>
> Russ> Luca Filipozzi writes:
> >> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
>
> >>> * Note that if you want to you can host accounts in gitlab and
> >>> hav
Hi,
On Fri, Apr 10, 2020 at 12:49 AM Enrico Zini wrote:
>
> The current sso.debian.org codebase has been written by one person (me),
> deployed by one person (me), audited by nobody, and as far as I'm aware,
> nobody besides me has ever read the code.
As a group, we are driving Enrico up the wal
On Wed, Apr 08, 2020 at 02:23:47PM +0200, Ole Streicher wrote:
> I don't know the exact proposed rules here, but I could imagine that
> without these rules anyone cann fill the namespace of nice Debian user
> names.
If you're talking spam account flooding the namespaces, they can be
cleaned up fr
On Wed, Apr 8, 2020 at 14:30:43 +0200, Bastian Blank wrote:
> Hi Zhu
>
> On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> No. The guest suffix was meant to avoid
Le 07/04/2020 à 18:50, Sam Hartman a écrit :
>> "Xavier" == Xavier writes:
>
> Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit :
> >> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
> >>
> >>> ## Highlevel plan
> >>
> >> I'd like to learn a bit about what the e
> "Russ" == Russ Allbery writes:
Russ> Luca Filipozzi writes:
>> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
>>> * Note that if you want to you can host accounts in gitlab and
>>> have keycloak act as an OIDC consumer for gitlab. So, if you
>>> decide y
Luca Filipozzi writes:
> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
>> * Note that if you want to you can host accounts in gitlab and have
>> keycloak act as an OIDC consumer for gitlab. So, if you decide you
>> like Gitlab as an IDP but find you need Keycloak's transformat
On Fri, Apr 10, 2020 at 12:06:42PM +0200, Bastian Blank wrote:
> On Wed, Apr 08, 2020 at 03:18:58PM +, Luca Filipozzi wrote:
> > > - Salsa, how should it work together.
> > Gitlab can use OIDC as an OmniAuth provider.
>
> And here the problems begin.
>
> Sure, just using it as OmniAuth provid
On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote:
> * I was right. Gitlab can work as an identity broker. They
> generally have people use keycloak to log into gitlab. However, there
> is one common app where it was easier to set up that app to consume
> gitlab than keycloak so
Hi. Speaking very much as an individual.
I just spoke to someone who runs a keycloak and gitlab instance for a
group of about 1000 users.
I wanted to inject their experience into the discussion, because having
operational experience is useful in such situations.
* The thing they like about ke
> "Luca" == Luca Filipozzi writes:
[All my statements in this thread have been as an individual, not as
DPL. I've offered to help Enrico facilitate consensus calling in this
discussion, and if he takes me up on that, such facilitation might not
entirely be separable from the DPL role when do
Hi Luca
On Wed, Apr 08, 2020 at 03:18:58PM +, Luca Filipozzi wrote:
> > - Salsa, how should it work together.
> Gitlab can use OIDC as an OmniAuth provider.
And here the problems begin.
Sure, just using it as OmniAuth provider works. But this only provides
authentication.
But, as Sam corre
On Fri, Apr 10, 2020 at 09:40:45AM +0200, Enrico Zini wrote:
> If you or someone else eventually will manage to introduce a Single Sign
> On system that would take us to a next step of being able to advocate
> developers, take packaging actions, update the ssh key you use to access
> debian.org ma
On Mon, Apr 06, 2020 at 02:34:03PM -0500, Michael Lustfield wrote:
> I was previously involved with a company that audited various git-hosting
> services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so
> please forgive the lack of specifics. Gitlab is a tool that gets many thing
On Thu, Apr 09, 2020 at 05:09:19AM -0500, Michael Lustfield wrote:
> It also appears that there is an intent to drop -guest naming. I haven't seen
> any technical discussion about this beyond learning about the current
> structure. I am very concerned that this will have significant consequences i
> "Tollef" == Tollef Fog Heen writes:
Tollef> ]] Enrico Zini
>> For guest accounts opened by DSA directly, it can be pretty much
First, at this point in time I would be very skepticle of someone
contributing to Debian enough to need porter box access but not having a
salsa account.
I
Hi,
On 4/8/20 2:30 PM, Bastian Blank wrote:
n Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
>
> No. The guest suffix was meant to avoid collisions with Debian
> account
On Thu, Apr 09, 2020 at 07:46:21PM +0200, Tollef Fog Heen wrote:
> > For guest accounts opened by DSA directly, it can be pretty much the
> > same: you can use the current Salsa account name of the person as the
> > username for the guest account.
>
> I don't think we want to make the Debian LDAP
]] Enrico Zini
> For guest accounts opened by DSA directly, it can be pretty much the
> same: you can use the current Salsa account name of the person as the
> username for the guest account.
I don't think we want to make the Debian LDAP service subservient to
salsa's, which this effectively wou
On Thu, 9 Apr 2020 09:44:38 +0200
Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote:
>
> > > If you're instead generally expressing a fear that once we migrate to
> > > Salsa, we'll be in a local optimum that is going to be considered good
> > > enough to be wor
On Wed, Apr 08, 2020 at 04:06:25PM +, Luca Filipozzi wrote:
> Another view point: I don't think that one's username should change as
> one's role(s) with the organization changes. If we could avoid that...
Agreed!
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signatu
On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote:
> > If you're instead generally expressing a fear that once we migrate to
> > Salsa, we'll be in a local optimum that is going to be considered good
> > enough to be worth bothering migrating to anything else, then I would
> > argue t
On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote:
> > There's another flow. Contributors interact with DSA in some process I
> > do not fully understand to get guest accounts on porter boxes etc.
>
> https://dsa.debian.org/doc/guest-account/
>
> I'd like to see a proposal on how
Le 08/04/2020 à 17:28, Luca Filipozzi a écrit :
> reminder: I'm replying linearly and from what I know (keycloak, SAML and
> OIDC).
>
>
> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
>> Le 05/04/2020 à 20:46, Bastian Blank a écrit :
>> I can help if you want to use lemondap-ng (LLNG:
>
On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote:
>
>(There's also the wiki account lifecycle, but that's completely separate
>and doesn't interact with any of the others, so we might want to keep
>that outside the discussion for now.)
Agreed! (as a wiki admin)
--
Steve McIntyre,
]] Sam Hartman
> There's another flow. Contributors interact with DSA in some process I
> do not fully understand to get guest accounts on porter boxes etc.
https://dsa.debian.org/doc/guest-account/
I'd like to see a proposal on how to avoid namespace clashes between
guest and non-DD salsa acc
On Wed, Apr 08, 2020 at 03:18:39PM +0200, Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:
>
> > > I understand you want to recognize DDs from other contributors, but why?
> > > Does it help you with permissions, does it help understand who someone
> > > is, or i
On Wed, Apr 08, 2020 at 06:23:29AM -0400, Sam Hartman wrote:
> Debian has two account life cycle work flows that we're reasonably happy
> with (or at least not proposing to change now).
>
> The first is the account life cycle for developers. DAM sends a signed
> ticket to keyring-maint and DSA, a
On Wed, Apr 08, 2020 at 05:28:37PM +0200, Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote:
>
> > > Question: is there something in the proposed Salsa plan that somehow
> > > blocks experimenting with, introducing, or migrating to Keycloak in the
> > > future?
>
reminder: I'm replying linearly (in this case, at the end of a chain of
email) and from what I know (keycloak, SAML and OIDC).
On Tue, Apr 07, 2020 at 04:08:37PM +0200, Xavier wrote:
> Le 07/04/2020 à 16:02, Enrico Zini a écrit :
> > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:
> >
> >
reminder: I'm replying linearly and from what I know (keycloak, SAML and
OIDC).
On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
> Le 05/04/2020 à 20:46, Bastian Blank a écrit :
> I can help if you want to use lemondap-ng (LLNG:
> https://lemonldap-ng.org https://tracker.debian.org/pkg/lem
On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote:
> > Question: is there something in the proposed Salsa plan that somehow
> > blocks experimenting with, introducing, or migrating to Keycloak in the
> > future?
>
> The further we go down one path, the harder, in my opinion, to chang
reminder: I'm answering these linearly and i'm speaking from what I know
(keycloak) not what I don't (LLNG). I expect LLNG is generally similar.
On Tue, Apr 07, 2020 at 08:53:47AM +0200, Bastian Blank wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> > That said, please co
I'm working through the responses linearly, so...
On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:
>
> > > I don't know keycloak: what are the maintenance costs, and what would be
> > > the benefits over time?
> > >
>
On Wed, Apr 08, 2020 at 10:05:19AM -0400, Sam Hartman wrote:
> I don't think it blocks your proposal, but I do think that having
> something to audit repos and make sure only current dds have access to
> certain repos is a valuable user no]eed.
> And I think the current-status-permission check nee
> "Enrico" == Enrico Zini writes:
Enrico> I agree that with the current proposal, the use case of
Enrico> "grant a person permission based on their status, which is
Enrico> somehow revoked or blocked if the status goes away" becomes
Enrico> something we might not be able to d
On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:
> > I understand you want to recognize DDs from other contributors, but why?
> > Does it help you with permissions, does it help understand who someone
> > is, or is it a habit that has been there since Alioth?
>
> For me, it's easier
> "Enrico" == Enrico Zini writes:
Enrico> On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote:
>> Sigh, but it makes sense too. Will nm.d.o have a field which
>> reflects the username on salsa?
Enrico> It finally will, yes! \o/
Enrico> It's been quite painful n
On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote:
> Sigh, but it makes sense too. Will nm.d.o have a field which reflects
> the username on salsa?
It finally will, yes! \o/
It's been quite painful not having that mapping so far.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-
On Wed, Apr 08, 2020 at 08:04:59PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> The reason why I ask for this is because
> 1. If a -guest account is added to a project in salsa Debian group,
> th
On Wed, Apr 8, 2020 at 8:33 PM Bastian Blank wrote:
>
> Hi Zhu
>
> On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> No. The guest suffix was meant to avoid collisio
Ulrike Uhlig writes:
> On 08.04.20 13:50, Shengjing Zhu wrote:
>> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote:
>
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is n
Hi Zhu
On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?
No. The guest suffix was meant to avoid collisions with Debian
accounts. And the tool used to enforce it is unmain
On Wed, Apr 8, 2020 at 8:13 PM Ulrike Uhlig wrote:
>
> Hi!
>
> On 08.04.20 13:50, Shengjing Zhu wrote:
> > On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote:
>
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> Could you explai
Hi!
On 08.04.20 13:50, Shengjing Zhu wrote:
> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?
Could you explain a bit better why you think that this is needed?
I understand you w
On Wed, Apr 8, 2020 at 7:50 PM Shengjing Zhu wrote:
[...]
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?
The reason why I ask for this is because
1. If a -guest account is added to a project in salsa Debian group,
the group name is a
On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?
I'll leave answering these questions to Waldi / Salsa admins.
I would like to stick to investing energy in solving problem
On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank wrote:
[...]
> ## Highlevel plan
>
> - Salsa becomes primary source of user info and authentication for secondary
> services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
> sso.debian.org.
> - Salsa allows user renames and drops
TL;DR: In Enrico's terms I'm an ACK not a NACK. I'm also trying to help
people considering whether they have blocking objections think about the
problems actually facing Debian.
I'm noticing a bit of a conflict here between people who are familiar
with Debian and people who are familiar with S
On Wed, Apr 08, 2020 at 04:51:49AM +, Paul Wise wrote:
> Is there any documentation and diagrams on the typical request flows
> between the browser the servers involved that happens with OIDC?
> Is there an OIDC demo site somewhere so that I can see the requests
> between the browser and the s
On Tue, Apr 7, 2020 at 6:23 PM Bastian Blank wrote:
> No, not really. The services ask the SSO service for the identity of
> the user and get an attestation back. So each service needs to handle
> it's own login.
Hmm, the OIDC documentation I've been able to find seemed to indicate
the login re
Hi Paul
On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote:
> It sounds like the answer is no, but does Salsa, Keycloak or
> LemonLDAP::NG support TLS client certs?
No, Salsa does not support TLS client certs.
> So it sounds like Debian would be switching our SSO authentication
> protocol
On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote:
> I'd like to learn a bit about what the effects for Debian account
> holders and service admins will be.
Thanks, I'll answer where I can.
I understand that you're exploring all possible corner cases that might
change and we might have t
> "Xavier" == Xavier writes:
Xavier> Le 07/04/2020 à 17:20, Paul Wise a écrit :
>> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
>>
>>> ## Highlevel plan
>>
>> I'd like to learn a bit about what the effects for Debian account
>> holders and service admins
Le 07/04/2020 à 17:20, Paul Wise a écrit :
> On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
>
>> ## Highlevel plan
>
> I'd like to learn a bit about what the effects for Debian account
> holders and service admins will be.
>
>> - Salsa becomes primary source of user info and authentication
On Mon, Apr 6, 2020 at 3:58 PM Bastian Blank wrote:
> ## Highlevel plan
I'd like to learn a bit about what the effects for Debian account
holders and service admins will be.
> - Salsa becomes primary source of user info and authentication for secondary
> services via OpenID Connect (OAuth2), f
On Tue, Apr 07, 2020 at 09:14:11AM -0500, Michael Lustfield wrote:
> I can very much appreciate a desire to get a replacement rolled out as quickly
> as possible. The more I learn about the current situation [1], the more
> alarming
> it is. However, please don't consider the work Lucas and I are
On Tue, 7 Apr 2020 13:50:06 +0200
Enrico Zini wrote:
> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
>
> I would like to avoid stalling progress on sso on things like analysis
> paralysis, or like sorting out deployment details, as happened in the
> last years.
I can very much appreci
Le 07/04/2020 à 16:02, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:
>
>> With a SSO, I don't think it's a good thing to have a protected app as
>> user database (even if it's possible). Then migration consists to
>> extract gitlab accounts and push them in LDAP (
On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote:
> With a SSO, I don't think it's a good thing to have a protected app as
> user database (even if it's possible). Then migration consists to
> extract gitlab accounts and push them in LDAP (2 branches, one for DD,
> one for guests)
Ok, pleas
Le 07/04/2020 à 14:38, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote:
>
>>> I'll ask you the same question I asked Luca: is there something in the
>>> Salsa proposal that would prevent further experimentation with LLNG and
>>> eventually possibly integrating it int
On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote:
> > I'll ask you the same question I asked Luca: is there something in the
> > Salsa proposal that would prevent further experimentation with LLNG and
> > eventually possibly integrating it into the ecosystem, or migrating to
> > it?
>
> No,
Le 07/04/2020 à 13:50, Enrico Zini a écrit :
> On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
>
>> Resume of proposition:
>> * all users managed by SSO; self-registration authorized with "-guest"
>>in a distinct LDAP branch
>> * GitLab becomes a slave of SSO using SAML (or OIDC)
>>
On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote:
> Resume of proposition:
> * all users managed by SSO; self-registration authorized with "-guest"
>in a distinct LDAP branch
> * GitLab becomes a slave of SSO using SAML (or OIDC)
> * other applications are protected by handlers/GateKe
Le 05/04/2020 à 20:46, Bastian Blank a écrit :
> Dear Debian fellows
>
> Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
> following plan. At the same time we declare the following services as EOL:
> - sso.debian.org and
> - parts of the Salsa self service interface.
On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:
>
> > > I don't know keycloak: what are the maintenance costs, and what would be
> > > the benefits over time?
> > >
> > > Right now, with the proposal waldi just posted,
On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote:
> > I don't know keycloak: what are the maintenance costs, and what would be
> > the benefits over time?
> >
> > Right now, with the proposal waldi just posted, we have very little to
> > no added maintenance cost, possibly negative
Hi Luca
On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> That said, please consider an approach that would see keycloak used as
> an idenitity broker, allowing external users to create accounts using
> social identities that are then promoted to full Debian identities (in
> LDAP)
On Mon, 6 Apr 2020 20:38:59 +0200
Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
>
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that
On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
>
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identitie
Dear waldi, Enrico,
On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote:
[many many details]
yay! many thanks for starting & doing this, this is gonna be awesome!
( & thanks to those helping making this happen as well! Either by action or
thoughts.)
> ## Exit plan
I especially like t
On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote:
> That said, please consider an approach that would see keycloak used as
> an idenitity broker, allowing external users to create accounts using
> social identities that are then promoted to full Debian identities (in
> LDAP) if they
On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote:
> We did not receive a response from DSA to date. We only got some personal
> remarks from jcristau and weasel on IRC. They don't want to handle Salsa
> differently and store information. Also they declared worry about user name
> co
Dear Debian fellows
Enrico (for NM and sso.debian.org) and I (for Salsa) intend to implement the
following plan. At the same time we declare the following services as EOL:
- sso.debian.org and
- parts of the Salsa self service interface.
We asked DPL, NM, DSA and the Salsa admins already for fee
91 matches
Mail list logo
