+1

Actually, I might have a worse problem: I installed and used the plugin for the first time today, and cannot find a way to avoid that everyone with a google account has access the jenkins instance. I tried playing with the 'Google Apps Domain' setting, but all I did was random attempts: I can't see on the Google Developers Console any value which has to do with a 'domain', so I have no clue how to use that setting.

Yeah, I've thought about this.

I guess this would be per-domain. Like "cloudbees.com:engineering" for a group called "engineering" in the cloudbees.com domain.

This would just be a list of principals for the user which you could then map into an Authorization realm like matrix-auth or cloudbees RBAC.

Perhaps this can be requested as a part of the oauth dance or as an optional followup API request.

If you want this to happen faster, please confirm the above information and provide me with links to which API's I should use. Or provide a patch! #lazyoss

Thinking about it more, its unclear to me if people would prefer to get the list of groups or organizational units.

I suppose that the groups are what are requested here. Perhaps populating the orgunit would be a separate feature request.

I notice that the G Suite API's also have notions of roles. I really have no clue what the use-cases and expectations are.

Just populating the groups as principles seems like it would address the crux of this request. Then you can go crazy with matrix-auth AFAICT.

We would like to be able to manage our users in this way - 

create groups in google g suite > make that group available to jenkins to be able to assign roles.

Not sure how difficult that would be but would be very useful to have.

+1

recampbell, I think most organizations would prefer to have this set by groups and not by organizational units. Normally, organizational units are for org charts and they are hierarchical.

Is there any progress on this feature request?

Same problems for us, we want to split admin role (credentials, main configuration, ...) from jobs management.

For this we think about two Google API options: Groups (already discussed here) and Roles API:
https://developers.google.com/admin-sdk/directory/v1/reference/groups
https://developers.google.com/admin-sdk/directory/v1/reference/roles

Most enterprise using Google OAuth already use 'Groups' that can be matched with Jenkins rights. Groups would be the easy way for many.

The 'Roles' way may offer more controls on rights, but could be more complexe to operate.

I've been looking at this as well today — but has anybody got experience with actually calling the G Suite admin APIs?

Using my non-admin account, I was not able to fetch the list of groups for my own account; I typically get a 400 error: https://developers.google.com/admin-sdk/directory/v1/reference/groups/list

It's unclear whether I'm doing something wrong, or whether implementing this functionality would require some sort of admin token, or maybe a delegated service account.

recampbell - in regards your pondering of Org Unit vs. Groups - my feeling is that mapping groups from GSuite to Jenkins makes the most sense.

Org Units are much more limiting since a user only exists in a single Org Unit (although OUs are hierarchical).

If you look at how GCP (Google Cloud) works, they let you assign groups directly into the permissions lists - so I can have engineering-team-X@example.com as a group with permissions on a given project etc.

The Google API for managing / querying users as groups is solid and well-documented - happy to discuss when you're available - you know where I am!

orrc - in regards your question about the API - the API is a bit finicky to setup initially.  

You have two options for calling the API

• a service account with appropriate scopes / permissions assigned
• a set of OAuth tokens for the "Jenkins" (or app), those token can then be used to issue an OAuth request (with required scopes) - which is basically a URL that a human will click on to generate a token. That token is then used by the Jenkins / app to issue directory HTTP requests.

The guidance from Google is that you can't use hard-coded tokens in OSS products (so Jenkins can't have a set burned in) - my gut feeling is that the most expedient way for Jenkins to work would be for end-users to create service accounts (this is not a GSuite user, but essentially a set of tokens) with the correct scopes.  The service account credentials would then be entered into Jenkins as another pair of credential fields.

This guide is the one I used - https://developers.google.com/admin-sdk/directory/v1/quickstart/go (There are Java versions of the same thing if that's more your style).  The example uses the "app" style token setup (rather than service account style setup)

Hey all, has anyone made any progress on this feature?

I have been looking at the source code for google-login-plugin to understand how it works, but the only unit tests currently inside are just validation unit tests for domain input.

I have been trying to write new mockito unit tests to test login, but i haven't figured out how to properly test authentication for plugins.

Does anyone have any documentation or examples on how to debug this kind of plugin?

Any updates on this ticket? It appears that someone opened a PR adding this functionality to the plugin back in January.

https://github.com/jenkinsci/google-login-plugin/pull/18

Hi Team,

Is there any update on this ticket, We are trying to add Gsuite group in Project-based Matrix Authorization Strategy but users part of that group are unable to login to jenkins. Currently we are adding individual users and providing permissions which is not feasible to manage.
Please let me know if there is any way to use Gsuite groups and use Project-based Matrix Authorization Strategy with it
for Jenkins 2.375.3.

Thank you!