Can't add second Google OpenID passport strategy

By: Dylan Goings user 11 Feb 2019 at 2:32 p.m. CST

10 Responses
Dylan Goings gravatar
## General description I'd like to be able to configure inbound OpenId authentication via Google for two separate google domains. I have created applications and obtained clientIds and secrets for both domains. I have passport setup and working. I can add the first google domain under the regular "google" passport strategy, but I can't add a second one with the same strategy name, so I have tried to follow the steps under the "Supporting a new strategy" docs here: https://gluu.org/docs/ce/authn-guide/passport/#supporting-a-new-strategy. But when I add the new strategy in oxTrust, the passport server fails to run and doesn't provide any logging as to why. ### Expected Behavior I can add a second custom passport strategy for a Google app. ### Actual Behavior Adding the new strategy causes the passport server to fail to run. ### Steps to reproduce 1. Copy the `google.js` file under `/opt/gluu/node/passport/server/auth` to a new file named `groundspeed.js`. 2. Edit `groundspeed.js` so that the `callbackURL` points to a custom url setup in the Google client app (e.g. `/passport/auth/groundspeed/callback`). 3. Edit `configureStrategies.js` to import `groundspeed.js` and check for `data.passportStrategies.groundspeed` (copy the check for Google and update names accordingly) 4. Edit `/opt/gluu/node/passport/server/routes/index.js` to import `groundspeed.js` and add sections to handle the new app callback: ``` //===================== groundspeed ================= router.get('/auth/groundspeed/callback', passportGroundspeed.authenticate('google', { failureRedirect: '/passport/login' }), callbackResponse); router.get('/auth/groundspeed/:token', validateToken, passportGroundspeed.authenticate('google', { scope: ['profile', 'email'] })); ``` 5. At this point, everything should still be working. Now add the new strategy to oxTrust under `Manage Authentication > Passport Authentication Method`. Name the strategy "groundspeed" and enter the client id and secret. 6. At this point, passport should automatically pick up the changes, but it doesn't. If you stop the passport server and try to start it again, it exits but without giving any errors, and `passport.log` doesn't show an error. Issue opened in Github for gluu-passport library, with screenshots: https://github.com/GluuFederation/gluu-passport/issues/57
Ubuntu 16.04
closed

Answers

By William Lowe user 12 Feb 2019 at 7:20 a.m. CST

Copy
William Lowe gravatar
Hi, Just to quickly level set -- in our terminology and workflows, inbound identity always means authentication at an external IDP other than your Gluu server. So to confirm your intended scenario: You want to allow users to hit your app, and then be able to authenticate at one of two backend Google authenticaton domains? A [web sequence diagram](https://www.websequencediagrams.com/) might help us better understand your intended workflow. Thanks, Will

By Dylan Goings user 12 Feb 2019 at 9:29 a.m. CST

Copy
Dylan Goings gravatar
Yes your understanding is correct. It is basically the Sample authentication flow described in the docs here: https://gluu.org/docs/ce/authn-guide/passport/#sample-authentication-flow. I have been able to get this working for a single Google oauth client. I have a single-page web app that sends a login request to the Gluu server as an OpenIDConnect client that's configured to use passport_social as the default acr. The user then sees a login page that shows external IDps that I've configured, like Google and Github, and is able to use those to login and be redirected back to the web app. The issue comes if I want to connect a second Google client (or second Github account, etc.).

By William Lowe user 12 Feb 2019 at 9:51 a.m. CST

Copy
William Lowe gravatar
> I have a single-page web app that sends a login request to the Gluu server as an OpenID Connect client that's configured to use passport_social as the default acr. So far so good. > The user then sees a login page that shows external IDps that I've configured, like Google and Github, and is able to use those to login and be redirected back to the web app. Yes, login page presented by Gluu, showing social login providers (a.k.a. external IDPs) connected via passport. Also fine. > if I want to connect a second Google client (or second Github account, etc.). This is the part that isn't correct. You don't need to adjust passport to configure additional *clients*. Passport strategies are simply used to connect external IDPs. Any additional clients that you want to leverage social login at your Gluu Server simply need to send the authentication request to Gluu with the passport acr -- no additional integration necessary with Passport.

By Dylan Goings user 12 Feb 2019 at 10:10 a.m. CST

Copy
Dylan Goings gravatar
> This is the part that isn't correct. You don't need to adjust passport to configure additional clients. Passport strategies are simply used to connect external IDPs. When I configure Google as a strategy for passport social login, I have to create an oauth app for my organization and provide the clientID and secret to Gluu. This is following the instructions here: https://gluu.org/docs/ce/authn-guide/passport/#obtain-client-credentials If I do that and then try to login using a google account that is not part of my organization, I get a 403 unauthorized error. > Any additional clients that you want to leverage social login at your Gluu Server simply need to send the authentication request to Gluu with the passport acr -- no additional integration necessary with Passport.' I'm not clear on what you're describing here. I think maybe I'm confusing terms. when I say additional clients, I mean a second Google organization, not another webapp. I don't want to just allow anyone with any Google account to be able to login, I only want people with accounts within my domain and another customer's domain to be able to login. Does that make sense?
Video or screenshot link

By William Lowe user 12 Feb 2019 at 10:11 a.m. CST

Copy
William Lowe gravatar
> Google client (or second Github account, etc.) Also, your phrasing here implies some conflation of the concepts... a client and an account are not the same. A client needs a user to authenticate at a provider in order to share their account information. So to put it simply: - connecting a client means you need to integrate an app with your Gluu Server - connecting an account means you need to integrate an external IDP with your Gluu Server

By William Lowe user 12 Feb 2019 at 10:15 a.m. CST

Copy
William Lowe gravatar
> I mean a second Google organization > How are the separate Google OPs differentiated? Can you give two example OP hostnames for the two external Google OPs? If you can give more specific details about the setup, we can try to replicate when we have some time.

By Dylan Goings user 12 Feb 2019 at 10:56 a.m. CST

Copy
Dylan Goings gravatar
These are the instructions we followed for setting up the google account: https://developers.google.com/identity/protocols/OAuth2UserAgent#creatingcred. The configuration looks like what's in the attached screenshot. This is configured inside our GSuite organization. The clientID and secret are put in the Gluu Passport Auth Method for the google strategy. So we might have the domain "ourcompany.com" and we're trying to login through Google with "dylan@ourcompany.com". Then we have a customer we are working with that we want to give access to our webapp, they have domain "customerA.com" and a user "william@customerA.com" is trying to login. We want to do a similar OAuth useragent setup inside their GSuite account. Perhaps we should be setting up the Google OP some other way?
Video or screenshot link

By William Lowe user 12 Feb 2019 at 11:14 a.m. CST

Copy
William Lowe gravatar
Ah.. ok, this is helpful context. Makes sense now. Two companies, two separate GSuite accounts, but only one OP -- Google. I think this is outside the scope of what passport is good for. Passport is intended for situations where you have distinct external IDPs for users, e.g. - `user1@company1.com` needs to get sent for authentication to `idp.company1.com` - `user2@company2.com` needs to get sent for authentication to `idp.company2.com` etc. etc. A better way to do this might be to limit access in your app based on a specific scope that is requested and obtained when a user authenticates. So now all users are still sent to Google for authentication, but only users that come back with the right scope are granted access. This is something you would configure in your application though, not your Gluu Server. Thanks, Will

By Dylan Goings user 12 Feb 2019 at 1:11 p.m. CST

Copy
Dylan Goings gravatar
Thank you, that does help clarify the problems we were having. We'll look into some other options for achieving the desired outcome. I believe one reason we were misled into thinking this was possible was the wording in the documentation about adding openid connect providers: https://gluu.org/docs/ce/authn-guide/passport/#external-openid-connect-providers Specifically the line "If you need to support a second OIDC provider, you have to duplicate the openidconnect strategy and proceed similarly as when adding a new provider." It sounds like you can just duplicate the passport scripts and configure them to reuse strategies. But overall this seems like a limitation of Passport not so much Gluu. Thank you again for your help!

By William Lowe user 13 Feb 2019 at 4:36 a.m. CST

Copy
William Lowe gravatar
I think the wording is actually correct.. if you need to add additional OpenID Providers, those are the steps. The problem is you weren't actually trying to add different OPs, you were adding the same OP twice -- Google. The two companies in question each have a "slice" of the OP, but it's the same OP with a single set of OP endpoints. If you want to suggest more clear wording, feel free to let me know. Thanks, Will

Post an answer