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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Using postgresql.org account as an auth id on third party websites
Дата
Msg-id CABUevEziizdTtchSz3-JN=-yF=7MA7yT_TYPBOK80_ML3wV+gg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using postgresql.org account as an auth id on third partywebsites  (Álvaro Hernández <aht@ongres.com>)
Ответы Re: Using postgresql.org account as an auth id on third partywebsites  (Álvaro Hernández <aht@ongres.com>)
Список pgsql-www
On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <aht@ongres.com> wrote:


On 18/9/19 3:45, Magnus Hagander wrote:
On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht@ongres.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

В списке pgsql-www по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Wiki editor request
Следующее
От: Álvaro Hernández
Дата:
Сообщение: Re: Using postgresql.org account as an auth id on third partywebsites