Re: Using postgresql.org account as an auth id on third party websites

On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <aht(at)ongres(dot)com> wrote:

>
>
> On 18/9/19 3:45, Magnus Hagander wrote:
>
> On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht(at)ongres(dot)com> wrote:
>
>>
>>
>> On 17/9/19 14:14, Jonathan S. Katz wrote:
>> > On 9/17/19 11:54 AM, Álvaro Hernández wrote:
>> >>
>> >> Great, thank you Jonathan.
>> >>
>> >> Now.... how do we register with the "central system"?
>> > Well, first make sure that it works :)
>> >
>> > I've not handled the registration process myself, but to test it, ensure
>> > you can authenticate against the test pgweb instance you've set up. You
>> > can configure it from the "Community auth sites" and "community auth
>> > orgs" part of the admin. So once that works, I think there can be the
>> > conversation of actually registering with the "central system."
>>
>> We can do that, no problem.
>>
>> >
>> > To date, apps that use community auth have been within pginfra (AFAICT),
>> > so to "formally request" it probably involves a longer conversation,
>> > either here or with webmaster@ as the process of doing so has not been
>> > exercised yet.
>>
>> Fair enough. Now.... I'd like not to waste any resources before
>> having that "longer conversation" then, which I hope it is not that
>> long. We're building a user authentication system on top of
>> https://postgresqlco.nf that will use external id providers like Google
>> Account, Twitter and others. We'd like to provide postgresql.org
>> community account as a first-class citizen authentication mechanism,
>> since this is something for the PostgreSQL Community as a whole. If this
>> is possible, great! If not, we should know asap and stick with the other
>> providers only --but I hope should not be a big deal.
>>
>>
>
> So far, we have only approved services running fully managed by the
> infrastructure team to handle this. Some of them are managed by different
> organisations (such as PostgreSQL Europe or PostgreSQL US), but since they
> are running on the main infrastructure there the team has the ability to
> reach and manage all the data.
>
> Right now, the system isn't really set up to handle things outside of
> that, as some things (particularly in relation to our new friend the gdpr)
> are handled completely manually and are not in the system. There are a
> number of things that should be implemented before doing something like
> that, such as the ability to push out a forced account delete (no API for
> that now). Or at the very least, a second level of consent about sharing
> data in an irretrievable way.
>
>
> Hi Magnus.
>
> You mention that this mechanism is already approved for different
> organisations. Indeed, this is where I saw it in action and loved the idea!
> But if it is approved for third-party (from a legal perspective)
> organisations, I don't see why it would not be for other third-party
> organisations. You mention GDPR and, if anything, that they are running "on
> the main infrastructure" (i.e. the infrastructure of a separate legal
> entity, I assume the PostgreSQL Canada Association) seems like something
> which may have serious GDPR issues on its own. I understand how things are
> down when being built, but have a look just in case ;)
>

Then your assumption is wrong.

Also note that my only mention of GDPR was in relation to there being
things related to that which are manual.

But back on topic, on what concerns my request: let's open this up to
> any third party organisation --it has already been done. I don't see why
> having "the team the ability to manage all the data" changes anything. What
> I'm requesting access to is a system for third-party authentication,
> similar to "login with Google" or any other auth provider. There's no
> "forced account delete" mechanism that I'm aware of, and there is little to
> no information sharing other than "hey, please authenticate this person and
> let me know the boolean information of whether that was successful or not"
> (optionally request name and email, as other authentication providers do,
> that is PII, but that's it). What auth providers do is a way to force
> delete a session (an authentication token, which typically expires quickly,
> but could be forcibly expired). This is optional, and in no way would force
> any deletion on the third party (it is the user who should use the third
> party's account deletion procedures).
>

Just because Google does something one way, doesn't mean that we want to do
it that way. We are allowed to treat our users better than Google treat
their tracking-victims for example, and would like to
stick to that level.

Oh, and as a general rule, "requesting" unpaid volunteers to do work for
you for free is in general not a great way to get them enthusiastic about
helping out.

In summary: it is already opened to third parties, please help us get
> to use it too, it's a very cool thing ;)
>

In summary, it is open to third parties *running on our managed
infrastructure*. That is a huge difference.

> If there isn't such a policy, TBQH I don't think this is an example
> of anything. And if there would be a policy, I believe that being a
> Community Non-Profit and/or running a Community conference should not be
> requisites for being able to use postgresql.org login. Why should they
> be related at all? If anything, this is about providing *conveniency*
> for PostgreSQL users to log into third party services without having to
> depend on other third party authentication providers which whom those
> users may feel less comfortable.

Why should they *not* be related? Again, this is a service provided for
free by volunteers. I'm pretty sure it's up to those volunteers to decide
what to do with their time.

> FWIW I also organize a Community Recognized Conference (https://pgibz.io
).

And I like that!

But you did not ask for this service for that conference. You asked for it
for a different site, run by ongres. So I'm not sure how that suddenly
became relevant?

> Good, I'm all ears. But I'm still surprised that technical bits are
> not required for PostgreSQL EU / US, they are separate entities and
> those bits (at least from a legal perspective) should apply equally.

As already answered, that is because those things are currently handled
manually, and they can only be handled manually if the people dealing with
them have full access to every part of every system that's in the mesh.
Which means that they run on our managed infrastructure. It would certainly
be better if that wasn't manual handling, but that's how it is right now.

Had the PGEU/PGUS systems run outside our infrastructure they would have
the same requirements. And had your service been running on the
infrastructure, it would not.

That part is at this point a technical problem. And in fact, it's
definitely one we'd like to see solved *regardless* of if it's opened up to
external access or not (because it's bloody annoying even when they are on
the same infra).

Would you be interested in working on that and providing a patch that can
be discussed/considered?

And with that fixed, we'd want at least a second level of consent (one
similar to how for example Google does it today, since you like to compare
to them), where you get a clear warning when you leave to an unrelated
site. Are you interested in working on that and providing a patch that can
be discussed/considered for that?

One thing that could probably be done easier, since it would be easier to
gain user acceptance on, would be if only the authentication and not the
sharing part were opened up. In that case, the external system would
receive the "yes this account is logged in" along with non-personal
identifier for that account (such as a uuid or hash), but not the PI. If
all you're looking for is alogin system, then perhaps that would be
enough? (It would certainly be a lot less work to implement)

> I don't know any other third-party authentication provider that
> does impose any limitation or requisite (other than checking for legal
> existence etc).

postgresql.org is not an authentication provider, so you cannot compare to
that. In regards to how the community authentication system works today it
is also not a third party, so you cannot compare to that either. So that
comparison is entirely invlaid.

> Just make it clear that the system does not come with a guaranteed
> SLA if that's your concern and that's fine. Use at your own risk, no
> guarantees of availability. Fine!

I'm sure you are well aware that is not how reality works.

When things don't work, people will complain. Somebody will be spending
time dealing with those complaints.

For example, just the other day I spent quite a bit of time debugging a
case of an account with conflicting email addresses caused by changing
multiple accounts between different email addresses. I was able to do this,
because I had full access to the systems on either side and could check the
constraints. Who will be doing that if there is no access and no technical
solution for deadling with it?

You also compare it to places like Google -- and it's true, their SLA is
"you're on your own". So basically, why are we even responding to your
questions on this thread? None of the other authentication providers you
mention would do that.

You may be happy to drop the SLA level to "ignore your users", but as that
would have an effect on existing users as well, no, some of us are not OK
with doing that.

We can of course say there's no availability on an integration to your
specific one. Heck, we can say that already now -- make up a crypto key and
run with it -- the redirects will still work, you don't even need us to
input anything! But I'm pretty sure that would also draw complaints.

>I may want to apply to be privileged too ;P

I am not sure what you refer to by privileged here, but you are certainly
welcome to volunteer. Approximately how many hours per week can you commit
to?

> I believe postgresqlco.nf is not a good fit for this use case, but
> thanks :) Still, I want to understand:

Why is it not?

> a) why having intertwined systems is a good and not a bad thing

Who said the systems are intertwined? You are again making assumptions
without facts. In fact, had they *been* intertwined it would've been a lot
easier to deal with the particular problems we have now. (For example, look
at how the previous version of community auth was done years ago)

> b) why this cannot be opened to any other third party (policy) and what
> is (technically) limiting it

This has been answered, repeatedly.

//Magnus