How to handle 2 accounts per user from Auth source

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

We have a LDAP Server as our Auth source, and this LDAP server reads users data from 2 locations. First the HR system and Second an Azure tenant (belongs to a subsidiary with their own HR that is not connected to ISC). Usually users in the HR system do not have a record in Azure, and vice versa. However, there are few exclusions to this where a user can have an account in both systems, resulting in 2 accounts per user in our LDAP server (which ISC is connecting to as Auth source), and hence 2 identities in ISC

What we would like to do is to have a single identity for these users in ISC.

Please consider addressing the following when creating your topic:

  • What have you tried?
    Correlate account from Azure with the identity created from HR using a field that is common in both
  • What errors did you face (share screenshots)?
    No errors
  • Share the details of your efforts (code / search query, workflow json etc.)?
    None
  • What is the result you are getting and what were you expecting?
    2 identities are created, and we want one identity created per user

Has anyone ever faced this scenario? How did you manage to handle this?

Any input would be appreciated.

2

I would say only correlation config is the only way. Look at these Identities, find some common attributes.

3

Thanks @KRM7
We already have a correlation in place using a unique field that is common in both accounts. However, it is still creating a new identity

4

Are the values in the same case in both sources? Some correlation rules are case-sensitive. The only way I’ve gotten around that is to export the source via SP Config, update the “ignoreCase” flag to true, then re-import.

There’s also the “Identity Fusion Connector” which may make sense to try to implement if you’re not already too far down the path of implementation to change course on something so foundational. New Capability: Fusion Connector for Identity Security Cloud! - Announcements / Product News - SailPoint Developer Community

1 Like
5

In my limited experience with ISC so far, it really doesn’t handle multi-account per source per identity all that well. Specifically when mapping attributes in Identity Profiles (e.g. which of the two or more auth accounts’ attribute do you want to match to the identity?), and, when provisioning out (no account selection policy).

So, with that, your concern is on the intake side of thing (i.e. not provisioning). With that, you can go with what Kevin is suggesting. The other alternative is to isolate those accounts as two different sources in ISC, creating two identity profiles, and hope that the profiles priority doesn’t conflict with the rest of your use cases / implementation. (e.g. Community supported solution vs SailPoint supported solution)

(To some extent, the LDAP is a multi-persona authoritative system in your case)

1 Like
6

I get it, just make sure Account ID attribute you set in Account schema is having same value for both the accounts. If it is different, it will create different Identity.

Correlation config and Priority applies when you have multiple Authoritative sources and respective identity Profiles.

– Krish

2 Likes
7

Wouldn’t that mean you’d lose visibility of one of the two accounts in ISC? Because you technically can’t / shouldn’t have two accounts of the same username / GUID / account ID on any system.

i.e. You shouldn’t see Account01 and Account01 again in a cube (regardless of which attribute is chosen as the Account ID).

#BugOrFeature?

8

I had a similiar scenario here.

Basically in my Auth Source(JDBC Connector) theres a few users that has two or more accounts. In my case all accounts has one account ID thats the same for all acounts but i have a column(Order) that says which accounts should be processed by ISC.
eg:
id | Name | Order | Key
1 | Yan Coelho | 1 | 1
1 | Yan Coelho | 0 | 2

My ID is my username in ISC, so even though i have more then 1 account it will correlate with the same identity.

Manager - We had to develop a manager correlation rule because ISC will always point to the first account that generated the identity.

Attributes: all transforms use a account sort attribute by my column Order to bring the right value.
eg:

{
    "id": "213213",
    "name": "Test-SortValidEmailLower",
    "type": "firstValid",
    "attributes": {
        "values": [
            {
                "attributes": {
                    "attributes": {
                        "sourceName": "Authoritative Source - Database",
                        "attributeName": "Email",
                        "accountSortAttribute": "Order",
                        "accountSortDescending": true,
                        "accountReturnFirstLink": true
                    },
                    "type": "accountAttribute"
                },
                "type": "lower"
            },
            {
                "attributes": {
                    "value": "[email protected]"
                },
                "type": "static"
            }
        ]
    },
    "internal": false
}

Accounts that should not be processed will always have the Column Order set to 0.

1 Like
9

If I do this we cannot control which account will create the identity right? My best guess is the one that is read later. In whichever case I suppose any one account will be used for creating the identity and other one will be entirely ignored. You think so too?

10

I replicated your usecase,

  1. If Account ID is different then multiple identities will be created
  2. If Account ID is same then Identity will be created with first record, but Identity attributes will be updated with 2nd record. So from next aggregation, only last record will be considered.

Maybe you should have 2 authoritative sources instead of 1 here.

Why do you have multiple records BTW ?

If there are multiple records which cannot be avoidable then is there a logic to ignore one account, I don’t think user records will be active in both the sources. Maybe you can use filter string to ignore one.

11

Thought so. That’s how IIQ behaves. It’s a “last one wins” / overwrite behaviour.

12

Thanks @KRM7 for your detailed response.

Our use case is quite complex as we are managing a group of companies under single IAM platform and all auth sources are channeled via one LDAP Server that acts as auth source for ISC. This configuration cannot be changed no matter what :smiley:

Unfortunately, we do not have an option to have same Account ID for both accounts and it does not look like there is a way we can avoid the second identity. Second best thing we are looking at is to somehow have the preferred identity to correlate with / provision accounts to target sources, which also seems like a challenge at this point of time.

13

I love your use case.

Technically we can handle your requirements one or the other way with some compromise as well.

What I am concerned with this is,

Creating extra Identities and Licensing

1 Like