[Koha-bugs] [Bug 10988] Allow login via Google OAuth2

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Jan 11 09:52:21 CET 2016


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988

Nicholas van Oudtshoorn <vanoudt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #46016|0                           |1
        is obsolete|                            |

--- Comment #61 from Nicholas van Oudtshoorn <vanoudt at gmail.com> ---
Created attachment 46473
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=46473&action=edit
Bug 10988 - Rewrite and renamed to OpenIDConnect

Fixes the concerns raised in comments 57 and 58.
Renamed the settings to OpenID Connect, as opposed to OAuth2, since that better
reflects what this is.

Detailed comments on the changes:

** MARTIN: Comment #57 **


> koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc
> I disagree with this change....
I take your point - and have removed the offending lines

>> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-auth.tt
> There's not enough added to this file.  There should be a 'login with your google id' block somewhere which appears to be missing.
You're right - that's in our customisations for our local site, but it makes
sense to do it here! Done!

> I think this needs rewording, it's a Google Login.. it's not automagic.. 
Fair point - reword to "Google login"

> I'm not seeing an state tokens in use anywhere in this Flow.. without them we are wide open to cross-site request forgery (CSRF) attacks.. we likely need to create a nice randomised string and store it between invocations of the script.
Done - I think. What do people think about the technique used. Wasn't too sure
about how Koha does session handling, but think it's working now...

** David: Comment #58 **
> Alternatively, you could put the ClientID and the ClientSecret in koha-conf.xml. While it would give less control to libraries, it would keep this information on a more "need to know" basis.

I personally think that it's better to put this in the preferences, since it's
possible to regenerate these at any time. It makes it easier for these to be
updated. Also, although they might be able to be changed, they can't be stolen
since they are only valid for the redirect_url for koha.

> How did you choose this endpoint? Both https://developers.google.com/identity/protocols/OpenIDConnect?hl=en#discovery and https://accounts.google.com/.well-known/openid-configuration provide versioned endpoints.
Good question - no idea. Fixed this now.

>tokeninfo isn't a standard OpenID Connect endpoint.
Moved to the proper endpoints now.

> As noted above, a standard response should be $json->{'iss'}, but otherwise this is good as per #2 at http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.
Fixed now
> As noted in #3 at http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation, $json->{'aud'} (the standard claim), "may" be an array. I'm not familiar with Google's responses... it might always return a string, but the spec points out that you should check for either a string or an array (and to reject the token if it doesn't contain the expected audience or if it includes untrusted audiences).
Put in a check to make sure that we're the only audience - but it looks like
google only sends us a string

> This is bizarre... the token shouldn't contain the email. That must be for debugging purposes in tokeninfo. You should have to get it from https://www.googleapis.com/oauth2/v3/userinfo or a similar endpoint, which also need its "sub" claim to be validated.
Moved to a different endpoint. Not sure that we need to validate "sub", since
we don't actually use it anywhere (Besides which, Google doesn't even think we
need to validate the token as much as we are - see 
https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo
for rationale)

> At this point, you must also verify that the token type is "Bearer" (case insensitive as per RFC 6749 Section 5.1).
Done
> At this point, you must also be verifying that the token isn't expired. 
Done
> You must also validate the "azp" claim if it's present in the response. 
Done
Oh, and as in reply to Martin, Forgery protection is also done







    Test Plan (remains the same):
     0) Back up your database
     1) Apply all these patches
     2) In your mysql client use your Koha database and execute:
        > DELETE FROM systempreferences;
        > SOURCE ~/kohaclone/installer/data/mysql/sysprefs.sql;
        -- Should be no errors.
        > SELECT * FROM systempreferences LIKE 'GoogleO%';
        -- Should see 4 entries.
        > QUIT;
     3) Restore your database
     4) Run ./installer/data/mysql/updatedatabase.pl;
     5) In your mysql client use your Koha database and execute:
        > SELECT * FROM systempreferences LIKE 'GoogleO%';
        -- Should see the same 4 entries.
     6) Log into the staff client
     7) Home -> Koha administration -> Global system preferences
     8) -> OPAC
        -- make sure your OPACBaseURL is set (e.g. https://opac.koha.ca)
     9) -> Administration
        -- There should be a 'Google OAuth2' section with the ability
           to set those 4 system preferences.
    10) In a new tab, go to https://console.developers.google.com/project
    11) Click 'Create Project'
    12) Type in a project name that won't freak users out, like your
        library name (e.g. South Pole Library).
    13) Click the 'Create' button.
    14) Click the 'APIs & auth' in the left frame.
    15) Click 'Credentials'
    16) Click 'Create new Client ID'
    17) Select 'Web application' and click 'Configure consent screen'.
    18) Select the Email Address.
    19) Put it a meaningful string into the Product Name
        (e.g. South Pole Library Authentication)
    20) Fill in the other fields as desired (or not)
    21) Click 'Save'
    22) Change the 'AUTHORIZED JAVASCRIPT ORIGINS' to your OPACBaseURL.
        (http://library.yourDNS.org)
    23) Change the 'AUTHORIZED REDIRECT URIS' to point to the new
        googleoauth2 script
        (http://library.yourDNS.org/cgi-bin/koha/svc/auth/googleopenidconnect)
    24) Click 'Create Client ID'
    25) Copy and paste the 'CLIENT ID' into the GoogleOAuth2ClientID
        system preference.
    26) Copy and paste the 'CLIENT SECRET' into the GoogleOAuth2ClientSecret
        system preference.
    27) Change the GoogleOpenIDConnect preference to 'Use'.
    28) Click 'Save all Administration preferences'
    29) In the OPAC, click 'Log in to your account'.
        -- You should get a confirmation request, if you are
            already logged in, OR a login screen if you are not.
        -- You need to have the primary email address set to one
           authenticated by Google in order to log in.
    30) Run koha qa test tools

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list