Google is closing it's OpenID2.0 endpoint

[frog32]

According to https://developers.google.com/+/api/auth-migration#timetable google is getting rid of their OpenID endpoint. Since every django-admin-sso user i know is using google as their OpenID provider we should take a look into google+ login.

[frog32]

Anyone else uses django admin sso with google? I am considering implementing OAuth2.0 https://developers.google.com/api-client-library/python/guide/aaa_oauth but i am not shure how i would deal with external dependencies. Any ideas? @meshy @adam-incuna

[meshy]

At Incuna we only use admin sso with google. I am personally a little disappointed at being forced by Google to have a G+ account for my work email address, so I will be a little hesitant to use G+ unless there is another option. I will be looking into using Persona, I suspect.

That said, I suppose one should make an effort to move with the times...

What external dependencies are you referring to? I seem to remember some talk of a python implementation of oauth2 somewhere a year or two ago...

[ghickman]

OAuth2 appears to be quite painful to use. There is a project trying to help though: oauthlib

@frog32 – Which external dependencies are you worried about?

@meshy – Persona has been left to the community now and is no longer being actively developed by Mozilla so it might not be the best path to take. However there are libraries for it already at least.

[meshy]

@ghickman oauthlib is exactly what I was thinking of, thank-you.

[frog32]

As far as i know you don't need to upgrade your profile to G+ (Google+ Sign-In works for all users with a Google account, whether or not they have upgraded to Google+. https://developers.google.com/accounts/docs/OAuth2Login#libraries). The thing which i find a little bit ugly is that we either drop openid support and migrate to oauth or provide support for both of them which would require installing both libraries.

I would use https://github.com/google/oauth2client and implementation seems to be quite easy. The only downside is, that you need to register every new instance and the return url for them.

Right now i could get a login by using the following code in a python shell:

from oauth2client.client import OAuth2WebServerFlow flow = OAuth2WebServerFlow(client_id=client_id, client_secret=client_secret, scope='email', redirect_uri='http://127.0.0.1:8000/admin/admin_sso/someendpoint/')

code = 'this value is a get parameter of the returning browser'

credentials = flow.step2_exchange(code)

credentials.id_token['email'] credentials.id_token['verified_email']

Is anyone using django-admin-sso with a openid provider which is not google? If not it wouldn't be to bad to drop openid support and move to oauth2.0

On 10.06.2014, at 15:49, Charlie Denton notifications@github.com wrote:

At Incuna we only use admin sso with google. I am personally a little disappointed at being forced by Google to have a G+ account for my work email address, so I will be a little hesitant to use G+ unless there is another option. I will be looking into using Persona, I suspect.

That said, I suppose one should make an effort to move with the times...

What external dependencies are you referring to? I seem to remember some talk of a python implementation of oauth2 somewhere a year or two ago...

— Reply to this email directly or view it on GitHub.

[frog32]

I got a working spike using oauth2client ready. https://github.com/frog32/django-admin-sso/tree/spike-oauth2client Since there is no easy way to introduce these changes an option would be to bump version to 1.x and drop openid support. The assignments table could stay the same so upgrading from 0.1.x to 1.x would be easy as long as you used google and no other openid provider.

[sspross]

:+1: dropping openid support is fine for me, following google :-/

[frog32]

I just checked the domains of all the stars on this project. What seems to be their primary company always uses google apps. There is one account that doesn't seem to use google apps but it also has starred 44k projects so i don't think they use django-admin-sso

[frog32]

A version using oauth is now working and has already a higher coverage than we had bevore https://travis-ci.org/frog32/django-admin-sso/builds/27323104 Is someone against replacing openid with oauth. The only things needed to upgrade would be to add the client id and client secret from the google developer console to the settings or inject it using an env variable.

[meshy]

I have no significant objections to the change, but I'm not sure if this is the right place to ask. Perhaps it would be best to release a version with a deprecation warning in order to warn people of the change?

[frog32]

I've thought about doing another release in the 0.1.x series to ship all the recent changes for python 3 compatibility. Since everyone is affected by this change i would have to raise this warning when the models file is loaded. But i am not sure if it's a good idea to raise a deprecation warning and give the users no way to get rid of it. Any ideas? I've thought about having a settings flag DJANGO_ADMIN_SSO_USE_OPENID = True to suppress the warning and raise an error in the newer version of django admin sso if this setting is set. Like that it would still be possible to use it with openid as long as you stay on a <1.0 release.

[meshy]

I'm not sure it's a good idea to ship the python3 stuff yet, as in order to get it to work you need to turn on the potentially insecure pickle (rather than json) serialisation.

I'm not sure about the setting...I wonder if the two methods could be shipped side by side? That would allow users a sensible way to remove the deprecation warning -- upgrade.

[frog32]

I've merged the openid and oauth code to allow a deprecation period for openid. Right now it uses oauth if there is a DJANGO_ADMIN_SSO_OAUTH_CLIENT_ID set. Unit tests now run twice with two different settings files and skip the oauth/openid specific tests in one run. Now there is some documentation work left but i would be happy to get feedback on my current changes.

[frog32]

The most recent version is now in the develop branch and has a 1.0.0 pre version number.

@adam-incuna this may solve your python3 problem by migrating to oauth2client

[frog32]

Just released v1.0.0 https://pypi.python.org/pypi/django-admin-sso/