Skip to content

E-Groups to GMS Migration

In Q3 of 2025, GMS will take over as the primary source of group information. Groups will continue to be synchronised back to Egroups. You are welcome to migrate in advance, and we appreciate any feedback you can provide!

How to migrate

Find your group in https://groups-portal.web.cern.ch/ and change the Group Synchronisation Option to Primary.

If you are using the API, send a PATCH request to update the syncType to Master (Note: in the GMS portal this has been correctly labelled Primary but unfortunately the underlying model has not yet been changed) as follows:

curl -X PATCH "https://authorization-service-api.web.cern.ch/api/v1.0/Group/GROUPID" \
  -H "Authorization: Bearer $API_ACCESS_TOKEN" \
  -H "Content-Type: application/json-patch+json" \
  -d '[
        {
          "op": "replace",
          "path": "/syncType",
          "value": "Master"
        }
      ]'

Best practices

  1. Check the synchronisation type of any associated groups. Any other groups included as a member or an admin of a group should be synchronised to Egroups to avoid inconsistencies, ensure their synchronisation type is not No Sync, and ideally is set to Primary.
  2. Applications can only be added to GMS primary groups. If you wish to include applications in your group admin group, ensure that it has sync type Primary. Applications are added to groups to grant them privileges when using the client credentials flow to authenticate - e.g. managing a group in GMS.
  3. Avoid circular dependencies. E.g. an admin group being added as a member of the group. This is not supported by Egroups and may result in undefined behaviour.

Membership translation between Egroups and GMS

To support coherent access control across the lifetime of a CERN User, Egroup members are matched to a CERN User Identity. An Identity contains information about the person, including their name and external email, and accounts linked to the person (e.g. their CERN account and personal accounts). Wherever possible, Egroup members are mapped to a corresponding User. Consequently you may see:

  • The total number of group members decrease - Multiple Egroup members resolve to a single Identity
  • The total number of group members increase - Same email resolves to multiple unassociated Identities

Example

Jane Doe is a STAF member in BE with a CERN account. She has linked her Linkedin account to her Identity so that she will be able to access her tax certificates & alumni platform after her contract ends.

Sync times

Creation in GMS

In this scenario the user creates a group at: https://groups-portal.web.cern.ch/

The table below shows the sync time for each type of application.

Application Sync time (maximum)
E-group 7 minutes
Active Directory 10-(?) minutes *
SSO Token 0 minutes for direct membership, 15 minutes for recursive

Creation in E-groups

In this scenario the user creates an E-group at: https://e-groups.cern.ch/

The table below shows the sync time for each type of application.

Application Sync time (maximum)
GMS 7 minutes
Active Directory 10-(?) minutes *
SSO Token GMS sync + 15 minutes for recursive membership
  • * The sync to Active Directory is from Egroups and depends on the sync queue and group size. It usually takes ~10 minutes but can take much longer.

Note: This includes the sync time for both static and dynamic groups.

Implementation note: Upper to Lower Case Conversion

Currently, in E-Groups it's possible to create a group with a mixed case name i.e aaAAaa-AAaaAA.

In GMS, only lowercase characters are allowed, meaning that any newly added group either directly to GMS or synced from e-groups will intentionally be switched to fully lowercase. The purpose of this convention is to add an extra layer of safety to our database entries.

Possible issues

The status of our services as described above has presented drawbacks for some of our users. In case a certain system aggregates data both from GMS and LDAP sources, this will result in inconsistencies regarding naming.

Solution

Advice towards our users who develop the systems and are in need of the above mechanism would be to implement a case-insensitive comparison. In this way each system is properly prepared to handle this convention logic, comparing just the name itself, ignoring cases.