Skip to Content
Technical Articles
Author's profile photo Gunnar Kosche

How to handle “usernames”, “Global User IDs” and “external IDs” in your landscape?

When it comes to setting up Identity Access Management (IAM) flows, we are often asked for best practices regarding usernames, Global User Ids and external ids. This blog post explains exactly this so let’s crack it !

In a nutshell, it is safe to say that it is good practice to avoid sensitive data when choosing a policy for usernames and IDs.

Here are some example of what sensitive data means:

  • credit card information,
  • user session identifiers,
  • customer data,
  • personal data / employee data.

The data type which is mainly processed in IAM context is personal data.

IAM admins might feel tempted to choose personal data derivations for usernames, Global User IDs and external IDs. This is bad practice.

Usernames, Global User IDs or external IDs appear in log files and other traces. DevOps who have access and authorisations to such log files might see personal data that they are otherwise not allowed to (need-to-know principle).

Furthermore if you use personal data in these attributes, the changes to values might not be applied, because the effort to keep track of audit-trails in log files would be too high. Keeping a history of multiple username- or external-ID-values over time (log files are read-only) is expensive. Some applications do not allow an ID change at all, which adds up complexity in the processes.

What is the difference between these attributes and when to use them?

The username is a mutable attribute which can be used for login hints like an email address, but which is also often distributed into applications.

Best described in the SCIM2 RFC7643 a username is the service provider’s unique identifier for the user, typically used by the user to directly authenticate to the service provider. Often displayed to the user as their unique identifier within the system (as opposed to “id” or “externalId”, which are generally opaque and not user-friendly identifiers).

Imagine your user is provisioned in various target applications and for business purposes (such as workflows), the same user must be uniquely identified between them. In this case, one needs a correlation attribute. We in SAP call it the Global User ID.

Also, in case the application requires data from another systems, it fetches it based on a mapping done via this correlation attribute.

The externalID is also described in the SCIM2 RFC7643 – it is mutable, defined by the client (and not the server) and optional within SCIM2.

The email attribute is often used in cloud services as login-name, as notification attribute and sometimes also as userID. Emails frequently contain personal data. The email is mutable and changes more often than we think. Name changes happen for several reasons but also domain changes in case of company changes. The email is easy to remember as login name and indicates the notification channel, but it creates headaches regarding Security, Data Protection and Privacy if the app doesn’t have other ways to identify the person at hand.

Best practices:

  • Generated usernames / IDs are better than manually assigned ones.
    First and foremost, admins should differentiate between the processes where the attributes are used. It is common to use personal data derived attributes (such as email or a human-friendly username) as logon aliases at the authenticating Identity Provider (IdP). On the other hand, for technical integrations which are not visible to the end user (such as SAML/OIDC flows or SCIM based replication), generate unique values without personal data as usernames, external IDs or Global User ID. Consider uuid formats because uuids are, for practical purposes, unique. Their uniqueness does not depend on a central registration authority and uuid does not contain derived personal data.
  • The usage of immutable IDs (referencing to mutable information) for the entire Identity Lifecycle.
    During the Identity Lifecycle, attributes such as lastname and email change. With stable identity identifiers the system to system communication continues without disruptions. The SAP Cloud Identity Services automatically generate the SCIM ID and Global User Id in uuid format for each record (The Global User Id is technically defined as mutable but there are rare reasons to change it during normal operations).
  • Avoid the usage of IDs in User Interfaces (UI).
    In the User Interface the technical identifiers should be replaced with human-friendly attributes. No one likes to be greeted in the morning with a Hello 0ae23960-721d-453c-8b1f-12eab5494e93!. Instead, what is being displayed in UIs or in self service portals should be a personal data attribute like the Displayname or firstname (belonging to the identity having this uuid). At the same time, DevOps engineers can observe in monitoring tools the successful authentication of a user based on the uuid value (or a username / external ID) without seeing any personal data.

You can find more details in the links bellow:


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Gunnar,

      great blog, thanks.

      I have a question about the SCIM ID, and I couldn't find anything specific in the IAS Help, except for this: The SCIM ID serves as the primary identifier. Users will only be updated, not created, if there are users with a new SCIM ID. This process works within the same tenant because SCIM IDs differ across tenants.

      In other words, the Global user ID can be changed, while the SCIM ID defaults to the global user ID but remains unchangeable. When should one use which ID? If there is more information available, please link it here. Thanks.

      Could you please take a look at this question and let us know how it is with PatchOp and SCIM API v2?

      Cheers Carsten

      Author's profile photo Gunnar Kosche
      Gunnar Kosche
      Blog Post Author

      Hi Carsten,

      It is the "id" of this record per SCIM definition. In case you create a new user in SAP Cloud Identity the "SCIM ID" is generated and used as the id of the corresponding SCIM-API. It is tenant and user record specific and immutable. You can use the value to access Cloud Identity via an API client directly to this record "/Users/<scim-id>" with GET/PUT/PATCH/DELETE requests. If you delete this record and create a user again with the same attributes the tenant generates a new SCIM ID.

      The "Global User ID" is defined as correlation ID across apps and services. It is mutable - but should not change often - we expect it to be stable for the identity. It can be written via API even during creation but can be also changed later which of course includes Cloud Identity Services. Newer SAP apps and services want to rely on the fact that the field is filled and distributed to the other apps/services that is why we pre-fill it with the uuid-value of the SCIM-ID.

      Example: It is possible to generate the "Global User ID" in Cloud Identity - production - and write the value into the corresponding user in Cloud Identity - test. Then a correlation is possible but the SCIM IDs are generated by each tenant.

      The "Global User ID" has also check and a history. If you change it to a current value of another user or an old value of another user it will not accept it because this breaks the logs and audit-trail and creates other issues but it is possible to change the value back to an older "Global User ID" of the same record. In case of a mistake writing wrong values for two users it might be necessary to create two new values as resolution.

      PUT is mandatory in the SCIM RFC and PATCH optional, but we foresee PATCH operations as critical for APIs because in enterprise apps/services we can expect big numbers of entities and PATCH works then more efficient.


      Author's profile photo Carsten Olt
      Carsten Olt

      Many Thanks for your answer!