OIDC issues with GCP

[Rokkart]

Hi everyone !

I'm working on a deployment solution of Dependency Track for my company. I'm using the docker compose setup.

I'm currently stuck with the authentication. I want to use the OIDC feature to manage the users. But I'm facing an issue about how GCP answers to Dependency Track OIDC requests.

Current Behavior:

When I try to use OIDC to connect to Dependency Track, I get an error in the API container logs telling me that the OIDC profil isn't complete. After a quick look, I see that I don't get any group for my user. So I guess that Dependency Track can't associate my user with a team. I'll put the error logs and configuration details in the 'Additional Details' section.

Steps to Reproduce:

I configured the compose file accordingly to Dependency Track documentation.
On the login form, I click the SSO button and connect to my GSuite account.

Expected Behavior:

I should be able to connect to Dependency Track with OIDC and get the permissions of the team I'm associated with.

Environment:

• Dependency-Track Version: 4.4.2
• Distribution: Docker
• Database Server: PostgreSQL
• Browser: Google Chrome

Additional Details:

Here is the error I get :
2022-04-21 08:09:17,261 ERROR [OidcAuthenticationService] Unable to assemble complete profile (ID token: OidcProfile{subject='*****************', username='**************@*********', groups=null, email='**************@*********'}, UserInfo: OidcProfile{subject='*****************', username='**************@*********', groups=null, email='**************@*********'}, Merged: OidcProfile{subject='*****************', username='**************@*********', groups=null, email='**************@*********'})

Here is the API Server config:

- ALPINE_OIDC_ENABLED=true
- ALPINE_OIDC_ISSUER=https://accounts.google.com
- ALPINE_OIDC_CLIENT_ID=*****************************.apps.googleusercontent.com
- ALPINE_OIDC_USERNAME_CLAIM=email
- ALPINE_OIDC_TEAMS_CLAIM=groups
- ALPINE_OIDC_USER_PROVISIONING=true
- ALPINE_OIDC_TEAM_SYNCHRONIZATION=true

Here is the Front Server config:

- OIDC_ISSUER=https://accounts.google.com
- OIDC_CLIENT_ID=*****************************.apps.googleusercontent.com
- OIDC_SCOPE=profile openid email https://www.googleapis.com/auth/admin.directory.group.readonly https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/admin.directory.group.member.readonly
- OIDC_FLOW=implicit
- OIDC_LOGIN_BUTTON_TEXT=Google SSO

There is a lot of scopes because I thought I needed all of these to get a group. Apparently it's useless since I need some admin permissions in order to use them.

As a workaround, I thought a default group for all OIDC users would to the trick. Is this possible to create such a group ?

Also, I use "https://accounts.google.com" as my OIDC Issuer. As I was looking for a solution, I saw that the issuer should be "https://accounts.google.com/o/oauth2/auth". I already tried this but Dependency Track can't request this issuer and returns a 404 error.

[AbdelHajou]

Can your users log in when you comment out the TEAM_SYNCHROINZATION and TEAMS_CLAIM properties? Some OIDC providers require additional configuration for group synchronization.

You could also try changing the TEAMS_CLAIM to groupList instead of groups

[AbdelHajou]

@stevespringett I think it would be useful to extend the documentation on OIDC configuration with some example configurations for cloud providers like Azure and GCP. I personally had a lot of trouble configuring Azure AD for my DT instance and it seems to be the same with GCP

[Rokkart]

Hi !
Yes my users can log in if the TEAM_SYNCHRONIZATION and TEAMS_CLAIM properties are commented out. That's the actual setup. That's why I asked if it's possible to create some kind of default group to assign to OIDC users (without these properties)

I don't have any groupList value with these scopes either.

I found an article of Rancher about this subject: https://rancher.com/docs/rancher/v2.5/en/admin-settings/authentication/google/
They are creating a Service Account to get the groups of their users. But it seems like they created this feature as a workaround.

[AbdelHajou]

@Rokkart I don’t think that’s possible yet, but that sounds like a good enhancement idea. Maybe every user should just be added to a Default group to make it easier for admins to manage permissions for new users

[valentijnscholten]

I have seen the error Unable to assemble complete profile when using Azure AD. I think in my case it was some kind of mismatch between frontend and api pod. After restarting them both it started to work. You probably already tried that, just mentioning it.

It might be useful to see if the error message thrown by DT can be made more descriptive. Maybe an error came back from the IdP causing the problem of not being able to assemble the profile? Or some data is missing in some token?

[nscuro]

@AbdelHajou I think it would be useful to extend the documentation on OIDC configuration with some example configurations for cloud providers like Azure and GCP.

The issue is that no one who successfully set up OIDC on these platforms has contributed documentation yet. Most of these services require subscriptions of some kind, which makes it impractical for maintainers to just go through all them and write docs for them.

@valentijnscholten Maybe an error came back from the IdP causing the problem of not being able to assemble the profile?

The error means that neither the ID token nor the /userinfo endpoint of the IdP provided enough info to assemble a complete profile. "Complete profile" refers to the sub claim (subject in the logs), the username claim and the teams claim (if configured). The claims can be present in either ID token, /userinfo or both. If you configure ALPINE_OIDC_TEAMS_CLAIM=groups and groups is not present in either of those locations, you'll see the Unable to assemble complete profile error in the logs.

[AbdelHajou]

@nscuro You’re right, I’ll try to contribute some documentation on how to set up Azure AD

[Rokkart]

@valentijnscholten I have seen the error Unable to assemble complete profile when using Azure AD. I think in my case it was some kind of mismatch between frontend and api pod. After restarting them both it started to work. You probably already tried that, just mentioning it.

Indeed, while I was trying to make it work, I restarted multiple times the stack, without any improvement.

As @nscuro said, the "groups" property is not returned by google with the scopes I configured. So it makes sense that in the error message "groups" is null. That's why in this article (https://rancher.com/docs/rancher/v2.5/en/admin-settings/authentication/google/) a Service Account is configured to get the groups with these scopes:

• https://www.googleapis.com/auth/admin.directory.user.readonly
• https://www.googleapis.com/auth/admin.directory.group.readonly

But DT is just not meant to work like this I guess.

Anyway thank you guys for your help. If anyone contributes to the doc or find a way to make it work, let me know ;)

[antrix]

@Rokkart I don’t think that’s possible yet, but that sounds like a good enhancement idea. Maybe every user should just be added to a Default group to make it easier for admins to manage permissions for new users

Hi @AbdelHajou - this feature would still be useful. Should I create a new issue to track it? I found #979 that can be re-opened?

[AkselAllas]

@nscuro Is there working group mapping for gcp?

Or when will 4.11 be released?

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.