Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OIDC groups scope not standard, causes oidc authentication to fail with some providers #1195

Closed
ken-ie opened this issue Feb 27, 2019 · 8 comments

Comments

@ken-ie
Copy link

commented Feb 27, 2019

When using Google as an OIDC provider, authentication fails due to an invalid scope, groups.
Error message returned by Google: invalid_scope and lists groups as the failure point.

It appears that groups is not part of the standard, but an optional scope supported by some providers.
(https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims)

To Duplicate (assuming a gcloud account already exists):

On Google
Select API & Services
Select Credentials
Select Create credentials
Select OAuth client ID
Select Web application
Enter the name, URL and redirect URL

On Argocd
kubectl edit configmap argocd-cm --namespace argocd

  oidc.config: |
    name: Argocd
    issuer: https://accounts.google.com
    clientID: [FROM ABOVE CRED]
    clientSecret:  [FROM ABOVE CRED]
@ken-ie

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

Same problem when using GitLab as a provider.
The requested scope is invalid, unknown, or malformed

@jessesuen

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

What is the equivalent scope in Google, GitLab for a list of groups a member belongs to?

@ken-ie

This comment has been minimized.

Copy link
Author

commented Feb 28, 2019

I'm not sure what the equivalent would be in Google. Their concept of groups was for communications. (Google Groups)

Here is their implementation of scope
https://developers.google.com/identity/protocols/OpenIDConnect#scope-param

They have a way to grant access to other APIs via scopes, but I'm not sure this would help.
https://developers.google.com/identity/protocols/OpenIDConnect#advancedtopics

And they have a LOT of scopes you could potentially access. None of them seem to be group oriented.
https://developers.google.com/identity/protocols/googlescopes

As for GitLab, I couldn't find much in the documentation on what they supported.
https://docs.gitlab.com/ee/api/applications.html

Just FYI, the code in question is in oidc.go

func (a *ClientApp) HandleLogin(w http.ResponseWriter, r *http.Request) {
	oidcConf, err := a.provider.ParseConfig()
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}
	scopes := []string{"openid", "profile", "email", "groups"}
@jessesuen

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

For GitLab, you would want to go the route of using the bundled dex server, with the gitlab connector:
https://github.com/dexidp/dex/blob/master/Documentation/connectors/gitlab.md

Also for Google, I think this should be possible by also using bundled dex with it's generic oidc.connector:
https://github.com/dexidp/dex/blob/master/Documentation/connectors/oidc.md

Would those solve your issue?

@ken-ie

This comment has been minimized.

Copy link
Author

commented Feb 28, 2019

Sadly, no. Our kubernetes cluster is completely locked down, we use kubectl port forwarding to access the system. That system will likely be replaced by a tunneling system in the future.

I tried using dex and ran into this:
#1062 (comment)

There might be a way to hack that around using your original suggestion. Perhaps using the internal cluster service hostname, and adding an /etc/hosts entry to the local device specifying that hostname as localhost(?) I may be able to try that tomorrow.

@jessesuen

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

I see. If there was a solution #1062 would this solve your issue?

I agree hardwiring groups is not ideal, but my hope was that Dex would solve most of the fragmentation issues for us by normalizing the OIDC providers into a set of expected scopes we can trust to be available. During testing, I tested with auth0, okta, onelogin which all seem to support groups out of the box.

Otherwise we would have to provide more and more oidc config options, which we will never be able to provide the same amount of functionality as Dex does, since this is not our focus.

@ken-ie

This comment has been minimized.

Copy link
Author

commented Mar 1, 2019

Yes, solving #1062 would work for our needs.

I think Dex probably is the best long term solution for SSO, for exactly the reason you said. It allows you to focus on the tool you are try to develop.

For now, I am going to actually stick with user/pass authentication, since I only have 2 others who will need access to ArgoCD. I can be patient for a fix.

@jessesuen

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

I have a solution for #1062 so I will dupe this to that bug.

#1211

@jessesuen jessesuen closed this Mar 1, 2019
@jessesuen jessesuen added the duplicate label Mar 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.