[Mailman-Developers] Architecture for extra profile info

[Xu Wang]

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 at 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:
>
>    1. When the application loads, it shows the you a "Login" link.
>    2. When you click that link, you are asked to login to Google and
>    asked to release basic account information to the application (user
>    consent).
>    3. If you grant consent, the application receives an access token.
>    4. 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)
>    5. 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 at gmail.com> wrote:
>
> On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen at xemacs.org
> >wrote:
>
> Xu Wang writes:
>
> On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
>
> stephen at 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 at xemacs.org;
> email:stephen.turnbull.fw at u.tsukuba.ac.jp; owner:
> fs-phil at turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta at xemacs.org ...;
> OpenID: stephenjturnbull at 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 at 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
>
>
>