Re: [Mailman-Developers] Architecture for extra profile info

My understanding of the use of oAuth to provide "login" information from Google, Twitter, etc. is based on the following description provided by Google.
Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain access to a Google API. It's a Python web application running on App Engine. The flow of the example is fairly straightforward: When the application loads, it shows the you a "Login" link. When you click that link, you are asked to login to Google and asked to release basic account information to the application (user consent). If you grant consent, the application receives an access token. Once it has the access token, the application presents the access token to the Google API that provides basic account information (https://www.googleapis.com/oauth2/v1/userinfo) The application renders the basic account information in a simple table. In particular, a user grants our server the permission to access some information pertaining to the user as it is stored by Google and accessed through their API for the purpose.
Based on that information, our server grants permission to the user thus identified and based on authorization data stored in our system. Once we have identified the user, our system can use tokens such as session keys, or other mechanisms, to maintain the association.
Richard
On Apr 28, 2013, at 2:42 PM, Xu Wang <xuwang@gmail.com> wrote:
On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
Xu Wang writes:
On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull < stephen@xemacs.org> wrote:
Xu Wang writes:
The problem is how do you "confirm ownership of the subscribed address" when a request coming with an access token.
You don't. That was done when the OAuth ID was linked to the address, using the usual 3-step handshake (submit the association, receive an email containing a secret, confirm ownership by replying with the secret).
I'm not sure what you mean by "OAuth ID".
In the case of Mailman's use cases, it will typically be an email address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID provider. Often, but not necessarily, it will be the subscribed address.
OpenID is about authentication. OAuth is about authorisation. What are we talking about here? Support to OpenID or support to OAuth or both?
As a resource server, the API need to validate the access token but
how to validate the access token is not part of OAuth.
This is some of the excess complexity (if you prefer, "enterprise readiness") in OAuth 2.0. In Mailman usage, the resource that the consumer gets access to will be a user ID. Eg, I might be "user: stephen; name: Stephen Turnbull; email: stephen@xemacs.org; email:stephen.turnbull.fw@u.tsukuba.ac.jp; owner: fs-phil@turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta@xemacs.org ...; OpenID: stephenjturnbull@gmail.com". So when I login via OpenID (which uses the OAuth v1 protocol AFAIK),
No OpenID does not uses OAuth protocol.
the provider (GMail) asks me to verify who I am by presenting my credential (most users will think of this as "getting the login screen"), and in turn it testifies to the client that I own that email at GMail, and the consumer (eg, the HyperKitty app) then looks it up, identifies me, logs me in as "stephen", and gives me a cookie (session auth token). The authentication *is* the validation here.
Mailman can't use GMail as OAuth provider to protect mailman's own resource as a general authorization solution.
OAuth v2 envisions more complex scenarios where the client may present
the same token repeatedly, or consumers might hang on to them and present them to the resource owner repeatedly, or even pass them on to other consumers. In those cases, yes, there will need to be validation etc going on. For example, the token might be a (ID, URI, expiration-date) tuple encrypted with the resource owner's private key. Being able to decrypt and getting a syntactically correct, unexpired tuple would then be validation of an authorization to fetch that URI. (In this particular case I'm thinking of "any valid user is OK".) This does require prior coordination between the provider and the resource owner on token format and exchange of keys.
But AFAICS Mailman's currently envisioned applications don't require this complexity.
As you put it, mailman don't have to support OAuth, but if it dose, it's better stick to the protocol.
Do you have any ideas for Mailman that might require something more fine-grained than just "this user is logged in"?
I'm new to mailman and have a very limited knowledge about what kind of "fine-grained" authorization it may need other than authentication. (read: Xu had no clue ...)
From the api implementation point of view, a role base authorization can be bundled in, which allows admin or resource owner to associate user with roles and roles with endpoints/methods.
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
Security Policy: http://wiki.list.org/x/QIA9

Well, it is about how a third party web application can get user's profile data from google as oauth client, like OpenID, it's little help on the access control of a third party RESTful API.
As oauth supported google's userinfo API, one need to present a valid google's oauth access token to get access. s/google/mailman/g on above statement, it will be true too.
If we are talking about enable OpenID or get user's profiles from google, facebook, tweeter, etc. as an OAuth client in postorius, it should not be a big deal because the client libs are readily available from those providers, but it is different from claiming mailman's api supports OAuth.
On Sun, Apr 28, 2013 at 6:47 PM, Richard Wackerbarth <rkw@dataplex.net>wrote:
My understanding of the use of oAuth to provide "login" information from Google, Twitter, etc. is based on the following description provided by Google.
Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain access to a Google API. It's a Python web application running on App Engine. The flow of the example is fairly straightforward:
- When the application loads, it shows the you a "Login" link.
- When you click that link, you are asked to login to Google and asked to release basic account information to the application (user consent).
- If you grant consent, the application receives an access token.
- Once it has the access token, the application presents the access token to the Google API that provides basic account information ( https://www.googleapis.com/oauth2/v1/userinfo)
- The application renders the basic account information in a simple table.
In particular, a user grants our server the permission to access some information pertaining to the user as it is stored by Google and accessed through their API for the purpose.
Based on that information, our server grants permission to the user thus identified and based on authorization data stored in our system. Once we have identified the user, our system can use tokens such as session keys, or other mechanisms, to maintain the association.
Richard
On Apr 28, 2013, at 2:42 PM, Xu Wang <xuwang@gmail.com> wrote:
On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen@xemacs.org
wrote:
Xu Wang writes:
On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
stephen@xemacs.org>
wrote:
Xu Wang writes:
The problem is how do you "confirm ownership of the subscribed address" when a request coming with an access token.
You don't. That was done when the OAuth ID was linked to the address, using the usual 3-step handshake (submit the association, receive an email containing a secret, confirm ownership by replying with the
secret).
I'm not sure what you mean by "OAuth ID".
In the case of Mailman's use cases, it will typically be an email address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID provider. Often, but not necessarily, it will be the subscribed address.
OpenID is about authentication. OAuth is about authorisation. What are we talking about here? Support to OpenID or support to OAuth or both?
As a resource server, the API need to validate the access token but
how to validate the access token is not part of OAuth.
This is some of the excess complexity (if you prefer, "enterprise readiness") in OAuth 2.0. In Mailman usage, the resource that the consumer gets access to will be a user ID. Eg, I might be "user: stephen; name: Stephen Turnbull; email: stephen@xemacs.org; email:stephen.turnbull.fw@u.tsukuba.ac.jp; owner: fs-phil@turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta@xemacs.org ...; OpenID: stephenjturnbull@gmail.com". So when I login via OpenID (which uses the OAuth v1 protocol AFAIK),
No OpenID does not uses OAuth protocol.
the provider (GMail) asks me to verify who I am by presenting my credential (most users will think of this as "getting the login screen"), and in turn it testifies to the client that I own that email at GMail, and the consumer (eg, the HyperKitty app) then looks it up, identifies me, logs me in as "stephen", and gives me a cookie (session auth token). The authentication *is* the validation here.
Mailman can't use GMail as OAuth provider to protect mailman's own resource as a general authorization solution.
OAuth v2 envisions more complex scenarios where the client may present
the same token repeatedly, or consumers might hang on to them and present them to the resource owner repeatedly, or even pass them on to other consumers. In those cases, yes, there will need to be validation etc going on. For example, the token might be a (ID, URI, expiration-date) tuple encrypted with the resource owner's private key. Being able to decrypt and getting a syntactically correct, unexpired tuple would then be validation of an authorization to fetch that URI. (In this particular case I'm thinking of "any valid user is OK".) This does require prior coordination between the provider and the resource owner on token format and exchange of keys.
But AFAICS Mailman's currently envisioned applications don't require this complexity.
As you put it, mailman don't have to support OAuth, but if it dose, it's better stick to the protocol.
Do you have any ideas for Mailman that might require something more fine-grained than just "this user is logged in"?
I'm new to mailman and have a very limited knowledge about what kind of "fine-grained" authorization it may need other than authentication. (read: Xu had no clue ...)
From the api implementation point of view, a role base authorization can be bundled in, which allows admin or resource owner to associate user with roles and roles with endpoints/methods.
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
Security Policy: http://wiki.list.org/x/QIA9
participants (2)
-
Richard Wackerbarth
-
Xu Wang