What is the use of "Federated ID" in user table?

[Suggy]

What is the use of "Federated ID" in user table?

PS - I am looking for use cases in real time for this field. Please dont share docs link 🙂

[VikMach]

Hi @Suggy,

The Federated ID field in the ServiceNow User Table (sys_user) is a unique identifier used to track identities across multiple ServiceNow instances. It was introduced in the Vancouver release and is generated using a hashing function based on a user's User ID and Email.

Business Use Case

The Federated ID is particularly useful for organizations that operate multiple ServiceNow instances and need a way to cross-reference users across them. When ServiceNow is configured separately to pull user records from same of different source(s) like Azure AD or LDAP or SAP, it will create a User record with new Sys ID in each instance. There are also scenarios where an employee gets married, divorced, or widowed and updates their name and email in the data source. In such cases, email alone cannot be relied upon to track the user's activities across multiple instances. However, when you have configured your system to create a Federated ID based on 2 or more unique "immutable" fields that generates the unique hash value then the user activities can be tracked across multiple instances.

To understand this, create 2 identical User Records (say Tiku Talsania) in 2 different instances with only User ID First Name and Last Name. You will see that both instances will create same Federated ID. Then add 2 different Email ID's in both instances. You will see the Federated ID will then change immediately. This is because in "Federated ID Criteria" application OOB, ServiceNow has set User ID and Email to be looked for Federated ID creation criteria.
There is a caution stating -
Caution! Your changes to the ID fields will result in the alternation of Federated Ids for all the existing records on the selected table. These changes may have implications on performance, compliance, and licensing.

Note - If there are users with duplicate user names and email, then the Federated ID is generated only for one user. If the user name is null or empty, then the Federated ID is null.

I know you have mentioned don't share doc link but there are some cautions you must take before making any changes or working with the Federated ID and you might want to read then analyze what action to take.
https://www.servicenow.com/docs/bundle/vancouver-platform-security/page/integrate/identity/task/conf...

If you wish to get that value updated, read before performing any action.
https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/integrate/identity/task/updat...

Source of knowledge is important. 🙂

Let me know if this helped!

Regards,
Vikas K

[Suggy]

Hi @VikMach  Thanks for the details, but still I did not get the practical use of this.

What is the real use case?

[Bert_c1]

See Google's AI response:

A federated ID, also known as federated identity management (FIM), is a system that allows users to access multiple systems or applications using a single set of credentials. It enables users to authenticate with one identity provider (IdP) and then seamlessly access other applications or services without needing to re-enter credentials. This is often implemented using technologies like SAML or OAuth. 

Key aspects of federated ID:

• Single Sign-On (SSO):

  Users authenticate once and can access multiple applications or services without re-entering credentials. 
• Trust Relationships:

  Federated ID relies on trust relationships between different organizations or systems. 

• Identity Providers (IdPs):

  IdPs manage user identities and authentication. 

• Service Providers (SPs):

  SPs (e.g., applications, web servers) rely on IdPs for user authentication. 

• Benefits:

  Improved user experience, reduced administrative burden, enhanced security. 

How it works:

• A user attempts to access an application or service. 

• The SP redirects the user to an IdP. 

• The user authenticates with the IdP using their credentials. 

• The IdP validates the credentials and, if successful, issues an authentication token. 

• The token is sent back to the SP, which then grants the user access to the application or service. 

Examples:

• Using your Google account to log in to other websites or apps. 

• Using your corporate email address and password to access company resources and cloud services. 

• Allowing users to sign in to Apple devices with their IdP credentials, such as their corporate email and password. 

[Suggy]

Sorry it did not help and not working.