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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez

     Hi list.

     AFAIK what I ask in $SUBJECT is available and used on some
websites, but is this documented? Is it based in Oauth2?

     It would be great to know more details :) Thanks,

     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Justin Clift-2
On 2019-09-17 14:00, Álvaro Hernández wrote:
>     Hi list.
>
>     AFAIK what I ask in $SUBJECT is available and used on some
> websites, but is this documented? Is it based in Oauth2?
>
>     It would be great to know more details :) Thanks,

Agreed, this would be useful. :)

+ Justin


Reply | Threaded
Open this post in threaded view
|

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

Nikolay Samokhvalov
In reply to this post by Alvaro Hernandez
+1 also wanted it, but could not find any information at all.

On Tue, Sep 17, 2019 at 7:00 AM Álvaro Hernández <[hidden email]> wrote:

     Hi list.

     AFAIK what I ask in $SUBJECT is available and used on some
websites, but is this documented? Is it based in Oauth2?

     It would be great to know more details :) Thanks,

     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Jonathan S. Katz-3
In reply to this post by Alvaro Hernandez
Hi Alvaro,

On 9/17/19 12:00 AM, Álvaro Hernández wrote:
>
>     Hi list.
>
>     AFAIK what I ask in $SUBJECT is available and used on some websites,
> but is this documented? Is it based in Oauth2?
>
>     It would be great to know more details :) Thanks,

The documentation for it is here:

https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob_plain;f=docs/authentication.rst;hb=HEAD

Note that a site that wishes to use community authentication still needs
to be registered with the central system. For testing purposes, you will
likely need to set up your own copy of pgweb.

Thanks!

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez


On 17/9/19 5:58, Jonathan S. Katz wrote:

> Hi Alvaro,
>
> On 9/17/19 12:00 AM, Álvaro Hernández wrote:
>>      Hi list.
>>
>>      AFAIK what I ask in $SUBJECT is available and used on some websites,
>> but is this documented? Is it based in Oauth2?
>>
>>      It would be great to know more details :) Thanks,
> The documentation for it is here:
>
> https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob_plain;f=docs/authentication.rst;hb=HEAD
>
> Note that a site that wishes to use community authentication still needs
> to be registered with the central system. For testing purposes, you will
> likely need to set up your own copy of pgweb.
>
> Thanks!
>
> Jonathan
>

     Great, thank you Jonathan.

     Now.... how do we register with the "central system"?


     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Jonathan S. Katz-3
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."

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.

Thanks,

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez


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.


     Thanks,

     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <[hidden email]> 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. 

//Magnus

Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez


On 18/9/19 3:45, Magnus Hagander wrote:
On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <[hidden email]> 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 ;)

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

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


    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres
Reply | Threaded
Open this post in threaded view
|

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

Stephen Frost
In reply to this post by Magnus Hagander-2
Greetings,

* Magnus Hagander ([hidden email]) wrote:

> On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <[hidden email]> wrote:
> > On 17/9/19 14:14, Jonathan S. Katz wrote:
> >      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.
I'd also point out that those other organizations are recognized
Community Non-Profits, and/or running Community recognized conferences.
That isn't an explicit 'policy' about what we run on pginfra or what
pginfra manages or is willing to tie things into, just to be clear, but
I do think it provides a good set of examples.

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

Yes, there's some technical bits too, but that might be something we
could work out a solution to.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stephen Frost
In reply to this post by Alvaro Hernandez
Greetings,

* Álvaro Hernández ([hidden email]) wrote:
>     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 ;)

If you believe there's a specific GDPR concern regarding what we're
doing, it'd be great if you could help us explain more clearly what that
concern is.

>     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).
I don't agree that we should open this up to just any third party
organization to use.  There's specific, recognized, organizations, who
also run on pginfra, who have been allowed to leverage this system but
saying that, say, Google, could use it, or any other organization
represents a de-facto endorsement of those systems which isn't something
that I think we, as a project, should be doing.

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

Those are very specific third parties which have requirements set on
them through our policies, not anyone, so this argument isn't valid.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez
In reply to this post by Stephen Frost


On 18/9/19 9:08, Stephen Frost wrote:

> Greetings,
>
> * Magnus Hagander ([hidden email]) wrote:
>> On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <[hidden email]> wrote:
>>> On 17/9/19 14:14, Jonathan S. Katz wrote:
>>>       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.
> I'd also point out that those other organizations are recognized
> Community Non-Profits, and/or running Community recognized conferences.
> That isn't an explicit 'policy' about what we run on pginfra or what
> pginfra manages or is willing to tie things into, just to be clear, but
> I do think it provides a good set of examples.

     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.

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

>
>> 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.
> Yes, there's some technical bits too, but that might be something we
> could work out a solution to.

     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.


     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Stephen Frost
Greetings,

* Álvaro Hernández ([hidden email]) wrote:

> On 18/9/19 9:08, Stephen Frost wrote:
> >I'd also point out that those other organizations are recognized
> >Community Non-Profits, and/or running Community recognized conferences.
> >That isn't an explicit 'policy' about what we run on pginfra or what
> >pginfra manages or is willing to tie things into, just to be clear, but
> >I do think it provides a good set of examples.
>
>     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.
I addressed this- having that tie-in is a de-facto endorsement of it.

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

Great!  Perhaps if it was hosted on pginfra then we could have it
included as part of the auth system.

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

The technical bits are around who manages the systems, not around what
the organizations are.  If you'd like us to host postgresqlco.nf, that'd
be a seperate discussion.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez
In reply to this post by Stephen Frost


On 18/9/19 9:13, Stephen Frost wrote:

> Greetings,
>
> * Álvaro Hernández ([hidden email]) wrote:
>>      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 ;)
> If you believe there's a specific GDPR concern regarding what we're
> doing, it'd be great if you could help us explain more clearly what that
> concern is.

     It's not really my concern, but more of a recommendation: just
review if all is good. If data from Postgres EU is managed by
infrastructure and staff from another organisation (PostgreSQL
Association in Canada) there should be several issues at play like: a
clear contract for services provision among the entities; clear policies
on how information is exchanged (and if postgresql.org login cannot be
opened to third parties as some data cancellation mechanisms are not in
place, this is a red flag IMHO that those mechanisms are not in place
right now for the EU Association); and possibly others. I'm not a GDPR
expert, but I'd recommend to review this. It sounds to me that things
are too intertwined between different orgs, where one is non EU. Clear
boundaries are required. I may be of course wrong and all this is
already in place.

>
>>      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).
> I don't agree that we should open this up to just any third party
> organization to use.  There's specific, recognized, organizations, who

     Why not?

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

> also run on pginfra, who have been allowed to leverage this system but
> saying that, say, Google, could use it, or any other organization
> represents a de-facto endorsement of those systems which isn't something
> that I think we, as a project, should be doing.

     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!


>
>>      In summary: it is already opened to third parties, please help us get to
>> use it too, it's a very cool thing ;)
> Those are very specific third parties which have requirements set on
> them through our policies, not anyone, so this argument isn't valid.

     Now what you say reads to me that there are some "privileged"
entities. I'd like to know more, why and how they are privileged. Can
you post here that policies that you mention? I may want to apply to be
privileged too ;P


     Thanks,

     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez
In reply to this post by Stephen Frost


On 18/9/19 9:20, Stephen Frost wrote:

> Greetings,
>
> * Álvaro Hernández ([hidden email]) wrote:
>> On 18/9/19 9:08, Stephen Frost wrote:
>>> I'd also point out that those other organizations are recognized
>>> Community Non-Profits, and/or running Community recognized conferences.
>>> That isn't an explicit 'policy' about what we run on pginfra or what
>>> pginfra manages or is willing to tie things into, just to be clear, but
>>> I do think it provides a good set of examples.
>>      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.
> I addressed this- having that tie-in is a de-facto endorsement of it.

     I see this more of a problem than a benefit, specially in the face
of GDPR, but also as a general principle. There are several entities at
play, there should be clear boundaries established.

>
>>      FWIW I also organize a Community Recognized Conference
>> (https://pgibz.io).
> Great!  Perhaps if it was hosted on pginfra then we could have it
> included as part of the auth system.

     That would be very cool. What do we need to do?

>
>>      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.
> The technical bits are around who manages the systems, not around what
> the organizations are.  If you'd like us to host postgresqlco.nf, that'd
> be a seperate discussion.

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

a) why having intertwined systems is a good and not a bad thing
b) why this cannot be opened to any other third party (policy) and what
is (technically) limiting it


     Regards,

     Álvaro

--

Alvaro Hernandez


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



Reply | Threaded
Open this post in threaded view
|

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

Magnus Hagander-2
In reply to this post by Alvaro Hernandez
On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <[hidden email]> wrote:


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

Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez


On 19/9/19 13:53, Magnus Hagander wrote:
On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <[hidden email]> wrote:


On 18/9/19 3:45, Magnus Hagander wrote:
On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Stefan Kaltenbrunner
On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>
>


[...]

>>
>> 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);

tbh as one of those volunteers, I kinda find it pretty irritating that
that the very first time somebody asks for community auth being opened
to non-pginfra managed sites an association of "us" not doing our job
correctly comes up just because that feature does not (and/or is not
implemented in the way you want it) do like.


> - or we do not have enough volunteers (which might, in turn, be the
> consequence of them being unpaid).

well again, there can always be more volunteers, but this discussion
seems to go the wrong way anyway.

When software and systems are designed one always considers various
usecases and scenarios - and whether you are paid for doing so or not
you have to make decisions and tradeoffs. There is no such thing as
designing for every possible usecase and ultimate flexibility and yet
still delivering an actual production service - and that is what we are
looking at here. Community Auth as we have it now is already a
next-generation service compared to what we had in the past (as already
said on the thread but it was never designed nor does we want it to be a
global authentication service for everything.
If _you_ want such a service feel free to propose patches to enable it
to be (suggestions on what needs to be done have been given on the
thread already) but consider the fact that we might not want to add even
more external dependencies on pginfra than we already have...


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

aha

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

so we are a few days into a discussion on enabling community auth for
non-pginfra managed services (which has never been done before) and your
analysis is already that we are "holding progress back"? Again I
consider that pretty offensive and demanding especially since there has
not been shown any evidence (to me at least) that doing this would
actually be "progress" and would allow things to move "forward"
(whatever "forward" might mean in that case). _You_ are asking for
something new and never done nor needed before - so implying it is
somebody elses "fault" seems weird - to say the least.


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

Among others - It was never designed for this use case in mind, it has
not been documented for this usecase and nobody has investigated any
time (yet) in actually making this supportable and maintainable in the
context of entirely third parties. Doing all this implies both on-time
effort and ongoing long term effort (if we do this with completely
external entities we also need to do long-term support of both the
infrastructure and the code) and again, postgresql.org is not a general
auth provider nor do we want to be one - so it is up to you to put
forward a workable proposal (and no - claiming this would enable
"progress" is not that).


>
>>
>>
>> >      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
>> <http://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.

it _is_ entirely different to run this service within pginfra or
providing it to external entities - whether you believe that or not is
up to you but it is a fact...


[...]

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

well you have nnot stated the "broader community" argument before, and
while I in fact see some merit in it - it is still a fact that the
current service has not been designed with that goal in mind , neither
from a code perspective nor is pginfra as team prepared for providing
this kinda of service to entirely external entities from a management
perspective.

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

Again - suggestions for code additions have been put forward, but as you
say people have to focus their efforts - the focus of community auth as
we have it now was not what you seem to want _now_.




Stefan


Reply | Threaded
Open this post in threaded view
|

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

Alvaro Hernandez


On 21/9/19 12:32, Stefan Kaltenbrunner wrote:

> On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>
>
> [...]
>
>>> 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);
> tbh as one of those volunteers, I kinda find it pretty irritating that
> that the very first time somebody asks for community auth being opened
> to non-pginfra managed sites an association of "us" not doing our job
> correctly comes up just because that feature does not (and/or is not
> implemented in the way you want it) do like.

     TBQH, I'm having a really hard time to understand how this
conclusion could be derived from my words. But it doesn't matter, it's
my bad anyway if I made you, or anyone else, feel this way.

     For the avoidance of doubt: Stefan, and any other pg-infra
volunteer or anyone else how felt bad about my words: my deepest and
most sincere apology. I never, under any circumstance, intended to do
any negative statement about the job done or the team itself. I have a
great deal of respect to any kind of volunteering in general, let alone
for the one on helping on the technology that I love. I have volunteered
tons of work on Postgres myself, and I cannot otherwise that feel in the
same page. pg-infra: I know the work that you do and have done, and I
really appreciate it, specially given how small team you are.

     On the contrary: if anything, what I wanted to say is that why
pg-infra is unpaid and relying on volunteers to do the job, specially
when there are economic resources? Why don't we combine volunteer work
with paid jobs to maintain pg-infra *and help it do more things*? The
fact that there are enough economic resources (and more that could be
raised if needed), some of which remain unallocated year after year, if
anything, signals a failure in precisely allocating them to the best
possible uses. And one of them could be to augment the current pg-infra
team.
>
>
>> - or we do not have enough volunteers (which might, in turn, be the
>> consequence of them being unpaid).
> well again, there can always be more volunteers, but this discussion
> seems to go the wrong way anyway.

     Or complement the team with paid jobs.

>
> When software and systems are designed one always considers various
> usecases and scenarios - and whether you are paid for doing so or not
> you have to make decisions and tradeoffs. There is no such thing as
> designing for every possible usecase and ultimate flexibility and yet
> still delivering an actual production service - and that is what we are
> looking at here. Community Auth as we have it now is already a
> next-generation service compared to what we had in the past (as already
> said on the thread but it was never designed nor does we want it to be a
> global authentication service for everything.

     I take it that it was not designed as a global authentication
service. But:

- I have asked repeatedly about technical details, nobody seems to
provide. I only hear abstract terms that are mostly common sense, but no
"meat". What are the limitations, what does it change that it runs on
shared infra, is there any description of the service, etc, etc, etc?

- The infra belongs to (AFAIK) to the PostgreSQL Association of Canada
(CA). As an example, the PostgreSQL Europe Association (EU) runs on CA's
infra. Both are, from a legal perspective, different legal entities.
Other than the possibly legal (is there a services contract among them?)
and GDPR issues, which I just raised as a potential warning for
something that might be revisited, why EU is (or needs to be) different
from other entities in the PostgreSQL Community?

     I'd argue that specially the latter creates a privileged
differentiation. If the service cannot be open globally, it should be
open to no one. Since I won't obviously argue for this, I argue to work
together and find a way to open it to third parties and fix this -from a
legal perspective discriminating situation- asap.


> If _you_ want such a service feel free to propose patches to enable it
> to be (suggestions on what needs to be done have been given on the
> thread already) but consider the fact that we might not want to add even
> more external dependencies on pginfra than we already have...

a) "send patches" is not the only way to improve the current state of
affairs
b) I still haven't heard any technical reason, so no, I don't know what
is holding this back or what the technical limitations are. I don't even
know what needs to be patched and why.
c) Running on shared-infra of another legal entity sounds already like a
privilege that either needs to be regulated or reverted. Being able to
consume services that others can because of that is even more privileged
and exclusive. I don't have anything against this, I know that things
evolve how they evolve, and that's more than fine. But maybe its time to
wake up and do things correctly. This email thread, if anything, I hope
it serves as a call to do improve these things. And this is not only "on
us, wanting to open community login to anyone".

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

     "Aha" meaning?

>
>>      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*.
> so we are a few days into a discussion on enabling community auth for
> non-pginfra managed services (which has never been done before) and your
> analysis is already that we are "holding progress back"?

     I said that:

- There's something done potentially incorrectly (that some community
members have privileged access to pg-infra and as well to services like
community login)
- I propose it be corrected and expose to anyone what is exposed to a
few privileged members of the very same Community
- All the Naysaying here is, yes, "holding progress back". Because there
is no "sure, let's work together on this" but rather "no, to
everything". Which is becoming a trend, lately....


> Again I
> consider that pretty offensive and demanding especially since there has
> not been shown any evidence (to me at least) that doing this would
> actually be "progress" and would allow things to move "forward"
> (whatever "forward" might mean in that case). _You_ are asking for
> something new and never done nor needed before - so implying it is
> somebody elses "fault" seems weird - to say the least.

     "Fault" is your term --definitely not mine.

     My apologies again if you felt offended. I won't insist more, I
believe I have clarified my position very well: what you say it has
never done before, it is done, and providing a service to one or more
entities of the PostgreSQL Community and *not being provided* to any
other entity in the PostgreSQL Community. I argue that should be changed
in the spirit of fairness and have everyone be equal. And I believe it
is progress because it may make people in the Postgres Community that
are not happy with the third-party authentication mechanisms of other
companies, to use the trusted PostgreSQL Community login on other
PostgreSQL-related services.


     Álvaro


>
>
>>
>>>
>>>          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.
> Among others - It was never designed for this use case in mind, it has
> not been documented for this usecase and nobody has investigated any
> time (yet) in actually making this supportable and maintainable in the
> context of entirely third parties. Doing all this implies both on-time
> effort and ongoing long term effort (if we do this with completely
> external entities we also need to do long-term support of both the
> infrastructure and the code) and again, postgresql.org is not a general
> auth provider nor do we want to be one - so it is up to you to put
> forward a workable proposal (and no - claiming this would enable
> "progress" is not that).
>
>
>>>
>>>>        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
>>> <http://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.
> it _is_ entirely different to run this service within pginfra or
> providing it to external entities - whether you believe that or not is
> up to you but it is a fact...
>
>
> [...]
>>      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.
> well you have nnot stated the "broader community" argument before, and
> while I in fact see some merit in it - it is still a fact that the
> current service has not been designed with that goal in mind , neither
> from a code perspective nor is pginfra as team prepared for providing
> this kinda of service to entirely external entities from a management
> perspective.
>
>>      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.
> Again - suggestions for code additions have been put forward, but as you
> say people have to focus their efforts - the focus of community auth as
> we have it now was not what you seem to want _now_.
>
>
>
>
> Stefan



Reply | Threaded
Open this post in threaded view
|

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

Dave Page-7


On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <[hidden email]> wrote:


On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
> On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>
>
> [...]
>
>>> 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);
> tbh as one of those volunteers, I kinda find it pretty irritating that
> that the very first time somebody asks for community auth being opened
> to non-pginfra managed sites an association of "us" not doing our job
> correctly comes up just because that feature does not (and/or is not
> implemented in the way you want it) do like.

     TBQH, I'm having a really hard time to understand how this
conclusion could be derived from my words.

It's exactly what I've inferred from your emails, and clearly I'm not alone :-(
 
     On the contrary: if anything, what I wanted to say is that why
pg-infra is unpaid and relying on volunteers to do the job, specially
when there are economic resources? Why don't we combine volunteer work
with paid jobs to maintain pg-infra *and help it do more things*? The
fact that there are enough economic resources (and more that could be
raised if needed), some of which remain unallocated year after year, if
anything, signals a failure in precisely allocating them to the best
possible uses. And one of them could be to augment the current pg-infra
team.

There are many reasons we're not doing that, not least of which are the matter of giving someone we probably don't know well keys to the castle and the fact that we're not setup in any way to employ or contract people and deal with the resulting management of them which also comes at a non-trivial cost, especially with a system such as pgInfra which has many moving parts.
 
- The infra belongs to (AFAIK) to the PostgreSQL Association of Canada
(CA).

That is entirely incorrect. PGCAC doesn't own any infrastructure at all.

The community infrastructure is owned mostly by the providers that kindly give us use of it, such as various contributing companies and hosting companies. We've only ever bought a couple of servers ourselves over the years, and that was through the SPI fund.
 
As an example, the PostgreSQL Europe Association (EU) runs on CA's
infra. Both are, from a legal perspective, different legal entities.
Other than the possibly legal (is there a services contract among them?)
and GDPR issues, which I just raised as a potential warning for
something that might be revisited, why EU is (or needs to be) different
from other entities in the PostgreSQL Community?

     I'd argue that specially the latter creates a privileged
differentiation. If the service cannot be open globally, it should be
open to no one. Since I won't obviously argue for this, I argue to work
together and find a way to open it to third parties and fix this -from a
legal perspective discriminating situation- asap.

Your argument is based on an incorrect premise.
 
> If _you_ want such a service feel free to propose patches to enable it
> to be (suggestions on what needs to be done have been given on the
> thread already) but consider the fact that we might not want to add even
> more external dependencies on pginfra than we already have...

a) "send patches" is not the only way to improve the current state of
affairs

It's one of the things that is likely to be required to make this happen though. There's a fair amount of convincing needed, though honestly I think you're doing a pretty good job of dissuading people from listening or wanting to help at the moment.
 
b) I still haven't heard any technical reason, so no, I don't know what
is holding this back or what the technical limitations are. I don't even
know what needs to be patched and why.

The main issue that I see at the moment is that the way Community Auth is written, authenticating through it will also share additional PII beyond the email address used to authenticate. Obviously we could warn the user about that, but we also need to consider how and when that would be done, i.e. would we have a flag in the system for "external sites" that aren't run by pgInfra, which would trigger additional consent? Or would we omit sending the extra info to external sites? Or maybe it would be better for us to just offer a SAML or oAuth service to external sites?

We would also need to consider how we deal with account deletion requests (or if we even need to).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
12