SSO Required User Attributes and NameID

Here are the required SAML attributes and identifiers (as per IDC’s specifications):

• SAML Subject NameID: This is the primary identifier for the user. It must be unique for each user in your company and should not change over time for a given user. IDC accepts the NameID in any of the following formats:
  • Persistent: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • Email Address: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
  • Unspecified: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  IDC previously required the NameID to be an email address, but now also supports persistent IDs. Recommendation: Use a persistent identifier if possible (a generated GUID or an internal user ID) as it decouples the login from an email which might change. If that’s not feasible, email address as NameID is acceptable. The key is it must be unique and consistent for each user.

  Why it matters: IDC uses NameID as the key to the user account. If two users share the same NameID, IDC can’t distinguish them – so it must be unique. Also, don’t reuse a NameID; if a user leaves, don’t assign their ID to a new user.

• Email Address: Provided as a SAML attribute. IDC expects the attribute with the name (URI) http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to contain the user’s email. This should be the corporate email and should match what the user would use as their login identifier normally.
• Given Name (First Name): Provided as attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname.
• Surname (Last Name): Provided as attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname.
• Common Name (Full Name): This one is optional. If provided, IDC will use it, but if not, it’s not critical. The attribute URI is http://schemas.xmlsoap.org/claims/CommonName. It’s essentially a display name. If your IdP doesn’t easily provide this, it’s fine to skip it.

In ADFS or similar, you’d issue these attributes as outgoing claims. For example, in ADFS you map:

• E-Mail-Addresses → emailaddress claim
• Given-Name → givenname claim
• Surname → surname claim
• (Common-Name → CommonName claim, if desired)

Ensure these claim URIs exactly match what IDC expects. Typos or different namespaces will result in IDC not seeing the attribute.

• NameID, email, given name, and surname are considered mandatory  by IDC.
  If any mandatory info is missing, the login will fail or be incomplete.
  • Specifically, if NameID is missing, IDC cannot process the login at all – the user will get an error and no account will be created.
  • If email is missing, similarly it’s a showstopper (since IDC needs an email for the account).
  • If given name or surname is missing, IDC will fallback by taking the part of the email before the “@” and using it as both given and family name. This prevents total failure but results in odd-looking names (e.g., “john.doe” becomes first name “john.doe”, last name “john.doe”). Users can later correct their name in their profile, but IDC recommends you send proper names to avoid this poor experience.
• CommonName is optional. It might be used for display purposes, but it is not required.

Generate a stable opaque ID for each user (could be a GUID or some hash). According to SAML spec guidelines, it should not be guessable; often IdPs generate a persistent NameID per SP, which is ideal.

Ensure the persistent ID meets the criteria: unique, persistent, non-reassigned. Meaning, if John leaves, you don’t later give John’s ID to Jane; Jane should get a new ID.

If you use email format for NameID, it’s okay but remember if the user’s email changes (due to marriage, etc.), their NameID would change, and IDC will treat them as a new user unless you update on IDC side. Some IdPs allow a stable internal ID even if email alias changes; that’s why persistent is often better.