How do I use Federated Login with OpenID Connect?

[NP]

Hello all,

I have an application (python) on GAE which uses Federated Login. In app.yaml, I have restricted some urls to be accessible only to admins (i.e. login; admin). According to GAE documentation, any url restricted to admin for applications using Federated Login will trigger a call to /_ah/loginrequired and I'm supposed to handle such calls by getting user to login using users.create_login_url(dest_url, federated_identity).

Documentation for users.create_login_url says if no federated_identity is specified (when your site is set to use federated identity), the system will default to Google as the OpenID provider. So the application currently defaults to  'https://www.google.com/accounts/o8/id' which is no longer supported by Google and I believe this is the reason why it gives me a 500 server error.

I have tried using the published Google Libraries for OpenID Connect. If I use the library outside of the create_login_url, I'm able to log in and get the user email but calling users.get_current_user() returns None and so the application doesn't see me as being logged in which means I don't get access to the url that I had restricted to admins. If I apply the OpenID Connect url to create_login_url, I get a 500 server error.

Does anybody know how to handle requests to urls restricted to logged-in users/admins using the new OpenID Connect?

[Nick (Cloud Platform Support)]

Hey NP,

This may very well be a side-effect of the decommissioning of Google's OpenID provider service and the moving to OpenID Connect. 

Could you link which "published Google Libraries for OpenID Connect" you've used, and if possible some of the code relevant to your use-case?

As noted in the docs, support for OpenID was experimental, probably since the landscape of Auth has been changing quite a bit, as new improvements are made through the experience of successive paradigms, however all I really need to comment on is that it was "experimental". Despite this, I'm committed to helping you find a solution that works.

There are several docs in our Developers resources which discuss OpenID Connect [1], [2], [3], and you might want to give those a read. If the login: admin feature turns out to have been specific to Google OpenID accounts, you can rest assured that:

A) A feature request in the public issue tracker to get this function updated to work with OpenID Connect is possible and awesome

B) you can implement your own admin feature using an admin check in your request handlers and implementing an OpenID Connect auth scheme which allows accounts from OpenID Connect services (you would add the various sign-in buttons to the sign-in page of your (web)app).

Best wishes,

Nick

[NP]

Hi Nick,

Thanks for your response.

On further research, I discovered that the Users API from google.appengine.api.users has no relation to the new Google OpenID Connect i.e. even after I've successfully logged in via Google OpenID Connect, calling Users.get_current_user() will return None. It seems Google has not yet provided a way for the Users API to work with the Google OpenID Connect. From what I understand if your application uses Federated Login, then there is currently no way to support urls restricted to admin or login required via app.yaml.

[Nick (Cloud Platform Support)]

Hi NP,

They do indeed appear to be presently parallel systems. You can explore the App Engine Users service and Google+ (OpenID Connect) authentication at the example app gae-login-explainer.appspot.com, which goes into some detail.

I think you've got the makings of a great feature request here, and encourage you to summarize the results into a Feature Request issue report in the public issue tracker, to request tighter integration of login: required / admin in app.yaml and OpenID Connect (Federated Login).

Best wishes,

Nick

[Jason Collins]

And make sure you link the feature request here; I'll gladly star it.

[NP]

I've logged a feature request.

Nick and Jason - Thanks

[Les Vogel]

You might wish to look into the Google Identity Toolkit for Federated Login / OpenID Connect.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/2e887ddd-4078-41d9-8710-809d2efea084%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Les Vogel | Cloud Developer Relations | le...@google.com | 408-676-7023

[Nick (Cloud Platform Support)]

I agree with Les Vogel, the Identity Toolkit (linked above) is what you'll want to look into for Federated Login / OpenID Connect. 

If you want to have an immediate solution to protected routes and also inter-operability with OpenID Connect, you could roll a simple database-oriented storage of certain users who are set as admins, and use checks of a client-supplied token passed through a public identity API against the stored emails of admins as a temporary solution until integration of OpenID Connect and the Users service is implemented (if so), and/or as a starting point to a more sufficiently-robust system of privileges and accounts on your app.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

Visit this group at http://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/2e887ddd-4078-41d9-8710-809d2efea084%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.