+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

As to the first commenter, you are doing something wrong. Just enter a valid Google apps domain and you will get a 401 if you select a user who isn't a member of that domain. Please open a seperate bug report with steps to reproduce if that doesn't work.

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.