Provisioning an Account Attribute ( Department ID instead of Department Name)

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello community,

I’m currently configuring a web server and I have a specific requirement for the Department attribute. Right now, only the Department Name is stored as an Identity Attribute, but what I actually need to provision to the source system is the Department ID.

How can I configure provisioning so that, when a user has a department assigned, SailPoint automatically looks up the corresponding department ID and sends that value to the source, instead of the department name?

I know that a Lookup Transform could be used, but since there are more than 50 departments — and new ones may be added by the client over time — maintaining such a lookup could quickly become difficult. I’ve also considered handling it in a before-provisioning rule with a map, but it feels like it would lead to the same maintenance issue.

What would be the best approach for this scenario?

2

Hi,

The easiest and best way is lookup transform. The lookup transform can handle any number of values, last time I remember we used over 4k codes and it worked fine.

Some or the other way we need to feed the info to system else it cannot pick the codes.

-Abhinov

3

Just throwing this out there, and not saying that I have done this, but I wonder whether a new entitlement type (single valued) may meet the requirement (and maybe others). Might be over engineered for this particular use case. But say you had an entitlement with name of Department name and value of Department id. Could a before provisioning rule then do the assignment?

4

We had a similar requirement couple of years ago and this is what we did:

  • Set up a new Delimited file Source to hold all Department names and IDs
  • Set this as an Auth Source and Set up an Identity Profile as well.
  • Account Attributes in the Source will be Department Name (set as ID & Name) and Department ID
  • In the identity profile mapping set UID as Department Name (which is automatic config anyway) and set Department ID as DisplayName (or any other attribute)
  • You can assign dummy emails (departmentId@yourdomain.com) and dummy first and last names (Department name for both)
  • An Identity will be created for each department as per above config. You can set these identities as LONG-TERM-INACTIVE so that they don’t show up in any certifications etc
  • As each user will have Department Name, use “Get Reference Identity Attribute“ to map the Department ID from Department Name
{    
    "name": "Departnemt ID from Department Name",
    "type": "rule",
    "attributes": {
        "name": "Cloud Services Deployment Utility",
        "operation": "getReferenceIdentityAttribute",
        "uid": {
            "type": "identityAttribute",
            "attributes": {
                "name": "departmentName" //*1
            }
        },
        "attributeName": "displayName" //*2
    },
    "internal": false
}
  1. Technical Name of Identity Attribute that is holding the Department Name in Employees Identity Profile
  2. Technical Name of Identity Attribute that is holding the Department ID in Departments Profile

However, flip side of this is that if a user does not have Department Name assigned, this transform will throw error. Only way I could figure out to handle this was to have a default Department Name and use firstValid transform around the Identity transform being applied to “uid” attribute in the above transform

1 Like
5

@torry_salamat this looks like a perfect solution for your use case.
@iamology Perfect!!

1 Like
6

Hello @iamology thank you for your answer but when implementing this the client said it’s too complicated for them and they want a more simple solution as they were using IIQ before moving to ISC do you have any other idea?

7

Hello @j_place , thank you for your answer this could be a great idea do you have any further information on this?

8

Hi @torry_salamat I’ve been thinking about this and Before provisioning may not be the best place for this as by that point a request is attribute and value rather than Entitlement, ie the Entitlement data construct may not be available at that point. However, Dynamic Role Dimensions may be your friend here.

Say you have aggregated or manually created your Department Entitlements with Department ID values. Create a Dynamic Role (say Department Role) with Department Identity Attribute as the Dimension Attribute. You can then map each Department Name value as a Dimension with the corresponding Entitlement as Access Item.

Pretty sure (I’ve not tested) that Dimensions can be added using the API for scripting purposes and then new Departments (or department churn) could be managed using the UI.

9

Hi Back @j_place thanks again for your answer,

Unfortunately we don’t have access to the Dimensions Tab because we don’t have the business suite plus tenant

I really don’t know how to deal with provisioning the IDs instead of the Names

I’m sure many clients have encountered this issue but i’m not sure how they dealt with it because it’s a really common usecase

10

Hi @torry_salamat Ah, right. TBH, the lookup transform then is probably your best bet. my understanding is that you can update that from API; so if you get proper change control around it, it might not be too bad.

11

  1. Please have a lookup transform with initial load of department Name –> department ID

  2. Ask your customer to provide a CSV file to be dropped on regular basis at defined FTP location / similar.

  3. Process CSV file and update your transform lookup table.

We did this for one of our customers and it works fine.

12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.