New Capability - Availability of new Identity Attributes, Default Identity Profile Mapping and Transforms

Announcements Product News
, , , , , ,
1

Description

:bangbang: We are excited to share that the new set of Identity attributes, default Identity profile mapping and two new transforms are now available in the Identity Security Cloud tenants onboarded after 2024-02-07 (i.e. 7th of February’24) which will save a significant amount of time for configuring Identity Profile and utilizing the new attributes across the Identity Security Cloud.

The following new capabilities are available in the Identity Security Cloud.

  1. New Identity Attributes
  2. Default Identity Profile Mapping
  3. New Transforms

New Identity Attributes

The subsequent number of default Identity attributes will save the time for utilizing them through out the Identity Security Cloud. We introduced 16 new set of default identity attributes as follows -

  • displayName: Middle Name, name: middleName, type: string
  • displayName: Preferred Name, name: preferredName, type: string
  • displayName: Initials, name: initials, type: string
  • displayName: Title, name: title, type: string
  • displayName: Organization, name: organization, type: string
  • displayName: Department, name: department, type: string
  • displayName: Cost Center, name: costCenter, type: string
  • displayName: Location, name: location, type: string
  • displayName: Location Code, name: locationCode, type: string
  • displayName: Street Address, name: streetAddress, type: string
  • displayName: City, name: city, type: string
  • displayName: State, name: state, type: string
  • displayName: Postal Code, name: postalCode, type: string
  • displayName: Preferred Language, name: preferredLanguage, type: string
  • displayName: Timezone, name: timezone, type: string
  • displayName: Identity State, name: identityState, type: string

Default Identity Profile Mapping

The default Identity profile mapping capability will optimize and streamline the identity profile mapping configuration process, offering a more efficient approach.

It enables the seamless creation of an Identity Profile by automatically establishing mappings between source attributes and default identity attributes, complete with the appropriate transformations. Consequently, when selecting a source and creating an identity profile, the predefined mappings are readily available on the mappings page. This not only saves time but also ensures a more comprehensive and user-friendly experience during the configuration of Identity Profiles.

As of now, the Workday connector has the default identity profile mapping mapped in the connector and it will be available in the other authoritative sources soon.

The Workday connector has following new account attributes which are also used in the default identity profile mapping -

  • PREFIX
  • SUFFIX
  • PREFERRED_FIRST_NAME
  • LOCALE_ID
  • Time_Profile_ID

The default identity profile mapping for Workday connector consists of following mapping and transforms,

Identity Attribute Account Attribute Default Transform
displayName WORKER_NAME Use Preferred Name
email EMAIL_ADDRESS_WORK -
personalEmail EMAIL_ADDRESS_HOME -
workPhone WORK_TELEPHONE -
phone WORK_MOBILE -
title JOBTITLE -
costCenter COST_CENTER -
department DEPARTMENT -
organization ORGANIZATION_NAME -
firstname FIRST_NAME -
middleName MIDDLE_NAME -
lastname LAST_NAME -
identificationNumber FILENUMBER -
manager MANAGER_ID -
uid FILENUMBER -
preferredName PREFERRED_FIRST_NAME -
startDate HIREDATE -
endDate TERMINATION_DATE -
faxPhone WORK_FAX -
streetAddress ADDRESS_WORK -
city CITY -
state STATE -
postalCode POSTAL_CODE -
country COUNTRY ISO3166 Country Format
timezone Time_Profile_ID -

NOTE -

  • This default mapping is applicable for new source and new Identity profile for the tenants onboarded after 2024-02-07 and it can be changed as per the customer’s requirement.

New Transforms

The new RFC5646 transform can be used to convert an incoming string into an RFC 5646 language tag value and new Use Preferred Name in Display Name transform can be used to form an identity’s Display Name value using the Preferred Name value when it exists over the Given Name value. The Family Name value is then appended to form the complete Display Name, e.g., (“Preferred Name” or “Given Name”) + “Family Name”.

NOTE -

For the tenants onboarded before 7th of February’24, the Identity Profile mapping configuration page excludes mappings and transforms for unavailable identity attributes and transforms. You can still add any of the newly created identity attributes or transforms manually as per your requirement.

What is the Problem?

Professional Services adds several identity attributes each time a tenant is created to make up for shortcomings of the current out-of-the-box (OOTB) attribute set. This slows implementations. A proliferation of inconsistent attributes across tenants also makes it harder to build features.

What is the Solution?

We have provided the new set of identity attributes along with predefined profile mapping and out of the box transforms that will provide quicker configuration and save a lot of time on the implementation.

Who is affected?

Applicable for the customers whose tenants are onboarded after 2024-02-07. Existing customers can still leverage it by creating custom Identity attributes.

Customer Communications

2 Likes
2

Hi Dinesh,

2024-02-07, given all possible date formats… do you mean 7th of Feb or 2nd of July?

If it’s the 7th of Feb with retroactive application, what will happen if tenants already have the Identity Attributes defined? (perhaps of a different type or with different mapping)

Will more standard connectors use these attributes / default mappings and do we need to align our attributes to match these?

Thanks in advance for your feedback!

3

Hi @dinesh_mishra,

We were on boarded in May, is this change already in sandbox and Prod tenants ?

We’re experiencing some issues with some of the identity attributes not bringing in data from Workday, esp. Cost Center and Department. We have provided the proper XPATHs as well. Just wondering if this change has anything to do with this issue we are facing? We’ve opened a support ticket for the same #CS0294213.

4

Hi @dinesh_mishra,

Thank you for the announcement!

Some questions from my side:

  1. Although this saves us time for customers who need these identity attributes. For the ones that don’t need them, the existence of these identity attributes might raise wrong expectations or assumptions and can cause confusion. Is it therefore possible for customers who don’t need these identity attributes to delete them? If they do, will that cause bugs next time we try to create an identity profile from an authoritative source with default mapping, or is your functionality taking this into account by only giving the default mapping that is still applicable to the tenant?
  2. All mentioned identity attributes are marked as string according to your announcement. But are there any more limitations or suggestions for values? I am asking this since we can create Email Templates in the API using a particular local attribute, which is a BCP 47 language tag. Right now this functionality is not working: Each identity always receives the English version of the email template. I hope it will be possible for SailPoint to allow us to choose an identity attribute that SailPoint will then check to determine which language to use when sending an email template. I can image SailPoint going to use preferredLanguage as the default identity attribute for this (hopefully we can still choose to use a different attribute). But does this mean that SailPoint will suggest customers to also ensure that preferredLanguage will contain a BCP 47 language tag like nl rather than a value like Dutch? If so, I think it makes sense to document that here as well to save customers troubles down the road.

Kind regards,
Angelo

5

Hi @tysremi,

It is available for the tenants onboarded after 7th of Feb’24.

If it’s the 7th of Feb with retroactive application, then there is no impacts at all if tenants already have the Identity Attributes defined, even for a different type or with different mapping.

Yes, there will be more standard and authoritative connectors which will use these attributes / default mappings; however, you don’t need to align your attributes to match these. If you want, you can do that but there won’t be any impact for the already created identity profiles, and identity attributes.

Thanks!

6

Hi @sharvari,

This changes are available in the production; and since your tenant was onboarded in May, this changes is applicable there.

However, the issue that you are facing is not related to this specific change. I would suggest to continue the engagement via support ticket which might be some configuration issue in the Workday connector.

Thanks!

1 Like
7

Hi @angelo_mekenkamp,

#1 - There is an option of not using the identity attribute that is not required. Customer can unselect the source for that attribute. Once it is unselected, the mapping goes away and the system will continue to work unless the attribute is not used anywhere else. Refer the image for the attributes for which the attributes are unselected,

image
image2458×1140 235 KB

Default identity attributes should not be deleted and it is not recommended to perform delete operation on such attributes.

#2 - Right now, we don’t have a plan to use preferred language in any other places and these newly added attributes are Strings. We don’t have any other limitations around it. Also, you can still choose to use a different attribute as per your requirement. Since it is flexible now, and up to the customer’s requirement; we are not suggesting any specific value for it. If there is any concern for it in the future, feel free to open a support ticket.

Thanks!

8

Hi @dinesh_mishra, could you please explain why the deletion of unused attributes is not recommended? (I assume in this context “… is not recommended” means the same as “SailPoint recommends not to …” – please correct me if I’m wrong).

If it is recommended not to delete the attributes because some internal SailPoint code depends on them, why not prohibit their deletion?

9

Hi @dinesh_mishra,

This will mean that even when we don’t have the identity attribute mapped in the identity profile, we will still see these identity attributes as columns in search, in the identity page (as empty, but appearing nonetheless) and maybe on other places as well.

So the current situation is:
1: Customers that want the identity attribute can create it themselves and map it in the identity profile.
2: Customers that don’t want the identity attribute can choose to not create it.

The new situation will be:

1: Customers that want the identity attribute have it directly (saves one step) and in certain cases it is mapped automatically in the identity profile (saves one step).
2: Customers that don’t want the identity attribute still get it, they are not allowed to delete it and on the identity page and in search it will show up. You have to scroll more in the mapping table in the identity profile to see the relevant values

I would consider this removal of choice/flexibility a step backwards. I understand SailPoint noticing a common pattern triggers them into wanting to optimize that pattern, but it should not come at a cost of customers that do not fit this pattern and rely on SailPoint allowing some customization. In addition I wonder if these enforced attributes will limit how many other identity attributes can be created or selected as searchable?

I hope SailPoint can revisit the idea of “making the choice of adding many specific identity attributes on behalf of new tenants without allowing them to remove them themselves afterwards.”

I really recommend you to align this with the product manager of Email Notifications (@Tyler_Harman), since it might be good for SailPoint to recommend a specific format here in preparation of the upcoming functionality of allowing multiple translations of email notifications (some countries even require employees to receive their emails in a specific language by law, so for international companies, this functionality should be in place).

Kind regards,
Angelo

10

Hi Andrei,

Right now, it is still possible for some attributes due to a bug which is being fixed. You are right that, once that is fixed, deletion of default attributes won’t be allowed. This is an existing behaviour and not specific with this new release; I would suggest to reach out to your support team if there is any other additional query.

Thanks!

2 Likes
11

Is there a method of suppressing the default attribute mapping (re: Workday)?

For example: ADDRESS_WORK

We do not want to aggregate this attribute, in addition to others, even on the account level.

  1. If we delete the xPath mapping, these automatically repopulate
  2. We cannot delete the attribute from the workday account schema, and once aggregated, we’re unable to remove the sensitive information without resetting (deleting) all accounts on the source
Unable to delete attribute "ADDRESS_WORK" because it is referenced by "attribute sync configuration".

**Trace ID:** d2cad3efe826407ca5a54ea828c0d213

* Field "ADDRESS_WORK" is mapped to identity attribute "streetAddress" by the default identity profile mapping for this source type.

And if we call the /attribute-sync-config for the workday source the response is

{
    "attributes": [],
    "source": {
        "id": "9b8d13f33f2****",
        "type": "SOURCE",
        "name": null
    }
}

All in all, the repopulating xPath in addition to not being able to delete the account attribute prevents us from removing sensitive information from our tenant.