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:
