We have about 100+ Jenkins users who belong to Google Apps domain and multiple Production Jenkins instances. As our Google Apps groups are reasonably maintained, I would like to make use of Google Groups for Jenkins Authorization too to simplify our operations.

      With Google Login plugin, it would be nice to able to map Google apps group to Roles for minimal configurations.

          [JENKINS-28010] Use Google Apps group for Authorization

          Ryan Campbell added a comment -

          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.

          Ryan Campbell added a comment - 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.

          Amo Chumber added a comment -

          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.

          Amo Chumber added a comment - 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.

          Thomas Wunderlich added a comment - +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.

          Amo Chumber added a comment -

          Is there any progress on this feature request?

          Amo Chumber added a comment - Is there any progress on this feature request?

          Florian Ramillien added a comment - - edited

          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.

          Florian Ramillien added a comment - - edited 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.

          Christopher Orr added a comment - 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 .

          Ben Walding added a comment -

          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)

           

           

           

          Ben Walding added a comment - 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)      

          Michael Dao added a comment -

          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?

          Michael Dao added a comment - 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?

          Jon Tancer added a comment -

          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

          Jon Tancer added a comment - 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

          Anuja added a comment -

          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!

          Anuja added a comment - 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!

            recampbell Ryan Campbell
            suresh_jayapal Suresh Jayapal
            Votes:
            27 Vote for this issue
            Watchers:
            35 Start watching this issue

              Created:
              Updated: