Re: Salsa as authentication provider for Debian

[Luca Filipozzi <lfilipoz@debian.org>]

On Fri, Apr 10, 2020 at 02:08:01PM -0400, Sam Hartman wrote:
> >>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
> 
>     Russ> Luca Filipozzi <lfilipoz@debian.org> 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
>     >>> transformations, you can have people login to Keycloak using
>     >>> their Gitlab accounts.
> 
>     >> I reiterate my point that an SP being an IdP. I don't view using
>     >> Debian's Gitlab as an IdP to be a prudent move.
> 
>     Russ> I don't understand this objection.  The relying party and the
>     Russ> identity provider are certainly different components with
>     Russ> different functions, but that doesn't imply that they can't be
>     Russ> combined in the same software suite.  There's quite a lot of
>     Russ> shared code between an SP and an IdP, so in some sense that's
>     Russ> easier than maintaining them as entirely separate projects.
> 
> I echo Russ's thoughts exactly.
> Russ and I both have a long history in the SSO world, and I think that
> if two people who have history say "we don't see the objection," it's
> a good idea to explore your objection in significantly more detail than
> simply asserting it.

I'm not saying that gitlab's IdP implementation is poor (another thread:
is discussing it's quality, however). The fact that gitlab shares code
between SP and IdP is not my concern.

Let me be more precise: I'm talking about the service itself and not
about the SP.

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.

Some organizations use their mailing list system (sympa, in particular)
as their group management solution.

None of this coupling between user management, group management,
authentication services and a specific service strikes me as prudent.

My observation is strictly related to the coupling of these things.

If I'm the only one with this concern, so be it.

-- 
Luca Filipozzi