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

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.

    I would not like to be otherwise. But I dunno. What you described seemed to me like PII and possibly other data, handled by different legal entities, under different jurisdictions (laws), is managed by the same group of people and shared, with no clear boundaries. I could be totally wrong, but I believe something might not be totally right there.

    Anyway, no worries: this is offtopic, I feel good I gave my feedback, I hope it helped (if at all to revisit this) and I would feel even better if all is absolutely correct. You are the President of EU, not me, so this is as far as I can get ;)

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.

    I used Google as an example. You came back with an unrelated, Google rant (????).

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.

    Did I do so? I don't recall where or when I said that.

    Irrespective of this: what you say I read as:

- Either volunteers, due to being unpaid, are not doing their job correctly (completely);
- or we do not have enough volunteers (which might, in turn, be the consequence of them being unpaid).

    AFAIK:

- PostgreSQL holds $142,000 on SPI of which less than $10,000 are allocated for use (https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting#09:35_-_09:40.09Funds_.26_Sponsors_update).
- PostgreSQL EU had by 2018's years end more than $200,000 in cash (https://www.postgresql.eu/about/ga/2019/financialreport/).
- PostgreSQL US has, as far as I know, half an order of magnitude more cash than EU.

    So... are we doing the right thing here, letting all this infrastructure be run by unpaid volunteers? Don't get me wrong, I applaud volunteers work and I love that some things are run by volunteers (and most of them/you are good friends, thank you!). But specially if the lack of extra hands *is holding progress back*, we're doing a poor job by not using the resources that PostgreSQL has (and more than I'm sure could be raised if needed) to move more things *forward* and *faster*.

    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.

    I understand the difference between running on the same managed infrastructure or not. But I don't understand --because despite the already lengthy thread nobody has stated what the reasons are-- why this factor makes a difference. Is the auth server a web service? Where it runs? What kind of authentication does it use that relies on the same managed infrastructure? It uses SSL certificates emitted by a custom CA? I can think of many things, please exemplify.

>      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.

    Because there shouldn't be a difference whether this service, which is already provided, is provided for a third party (that happens to run on one location) or provided to another third party (that happens to run on a possibly distinct location). Nobody is questioning volunteers work.

> 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?

    It became relevant when Stephen raised this and made it relevant. I only responded because I always try to respond to every concern raised.

> 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

    "those". What things? You are all talking in the abstract. You may have the context, I don't. I cannot understand without more precise details, I'm sorry.

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?

    Please let us know what needs to be changed, if it is code (and what code), infrastructure, whatever. I'm interested in providing help, given that it is within our area of expertise.

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?

    I'm surprised this second level of consent is not required for pgconf.eu. Can you explain why it is required for one use case and not for another use case.... when both uses cases happen to be the *same*?

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 like iterative approach to problems. This is better than nothing, but I still cannot understand what the problem is and what the different level of effort is required. Does pgconf.eu get any PII from the user login? If so, it should be done already.

> 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.

    postgresql.org, run by the PostgreSQL Association of Canada, is an authentication provider for some services run by other different entities (like the PostgreSQL EU Association in France). So why it cannot authenticate other third parties? There is no difference at all (or there should not be).

> 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?

    Correctness, legal compliance and equal provision of capabilities to any third parties sometimes requires the development of processes. Maybe some process needs to be developed here. Even if it would be more time consuming (which I doubt, if properly streamlined and designed). Because what you say sounds to me as:

- You are conflating roles, entities and concerns into peoples and entities that should be separate. This IMVHO needs to be fixed regardless of this discussion.
- There are very few people in your position (with access to the full infra of both PostgreSQL CA and EU) and that may become (maybe is already, apparently) a bottleneck. If concerns were appropriately separated, many other people could be on either side and given a process among them, it would be fixed easily and promptly.

    But anyway, I'm still puzzled by the level of tight coupling. An auth provider does not need to have any interaction from the consumer of the authentication service *at all* to operate. It is, indeed, one of its basic principles of operation.

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?

    Really, what do you mean? You don't need to reply to me if you don't want...

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.

    What I know is that not providing a service is worse than providing a service with best effort guarantees, specially if it is not something extremely demanding or used as of today, as it is the case.

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.

    What draws complaints is that there appears to be here "privileged" entities and not privileged entities.

>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?

    Refer above to the $ argument. Let's hire someone. I'm willing to donate money if there would be not enough funds for this.

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

Why is it not?

    postgresqlco.nf is a free service, developed and run by OnGres. I don't think is a good fit to run on a non-profit entity's infrastructure. Is PostgreSQL infra providing hosting services for companies?

> 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.

    I make assumptions based on the information that was provided in this thread, which with the lack of other context sounds like there is a lot of intertwined systems. I'm happy to stand corrected if more information is provided.

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.

    Not at all. Not a single tech reason has been provided.


    All in all: I wanted to provide PostgreSQL Community login because I felt it was a good thing for the PostgreSQL Community. For us, it means extra development effort where we have estimated that very few people, if anyone, would use. Most people are happy with *either* (Google or Twitter or GitHub or GitLab), which are the other auth providers we are implementing. So the only reason we wanted to provide this is to bring back here (as we do in many other areas) by "promoting" the use of the PostgreSQL Community account, to create a broader sense of Community. That services provided by the Community are available to the Community through a Community authentication system, and not relying on external providers like Google, given that we have one.

    Now if this causes this reaction against it, and it's that problematic, we will just simply forget about it and focus our efforts in other areas. But it honestly leave a very bitter taste: there appears to be some PostgreSQL Community services that are quite exclusive --in the literal sense of exclusiveness; and not the inclusiveness I'd expect from the PostgreSQL Community.


    Regards,

    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres