We have a requirement for a custom, secondary identity in SailPoint for a subset of users who require access to be segregated depending on their work location. It’s simpler to give them two identities vs. duplicate all of our provisioning workflows, since they will end up with multiple accounts on the same source.
We already have one authoritative source (HR system), but I’m thinking we will create a secondary authoritative source, TBD, for the secondary identities. That way a user will get their primary identity from the HR system, but we can manually request or provision a secondary identity using the second authoritative source.
My question is, what are my options for the secondary authoritative source? We have Active Directory and Azure, but I’m having a hard time wrapping my head around how that would work:
AD as an authoritative source → SailPoint → …back to AD as a provisioning target?
It feels weirdly circular and recursive to have Active Directory as an authoritative source and as a provisioning target for access requests, etc. I’m not sure that’s even possible.
What do other people do when you have a need to create one-off identities for small use cases? I know we can use a CSV import, but I’d prefer to use something a bit more robust than that.
I would recommend this.
Use a delimited source as secondary authoritative source.
Create a identity profile with source and give less priority.
You can design a form in SNOW or some where and make an API call to create a new user in this source and create identity.
Once the identity is created you may request the AD account and others as well.
I would not recommend using AD as auth source because of this.
You might end up creating multiple AD source in SailPoint one for auth source another one for provisioning.
It is not recommended to use same source as auth and provisioning source. Initially it might be easy going forward it will be difficult to keep track of changes
Moreover if you have password feature enabled you can configure only one AD source in your PWI to sync the password.
So considering all of these limitation it is better to use other source apart from AD
The statement from you
"We have a requirement for a custom, secondary identity in SailPoint for a subset of users who require access to be segregated depending on their work location. "
do you want to segregate at ISC platform level? or end systems level?
we have role criteria to segregate upon location or some info. I am not sure why you need secondary identity in ISC.
We need a separate identity because we don’t want to have to duplicate all our sources and roles for the secondary accounts. Since SailPoint is not really set up to allow multiple accounts on a single source, a separate identity makes the most sense.
so correct me if i am wrong: actually you need secondary accounts for end systems based on location, to achieve this you are thinking to create one more identity profile with auth source?
Yes, that is correct. To simplify it a bit, the use case is that I need to use account A for when I’m in one office, and account B for when I’m in a different office. And I cannot use account A in office B and vice versa. But I need access to all the same sources, apps, and roles otherwise.
So how can I assign two accounts to a single user on (potentially) all sources? Based on everything I know about SailPoint, you cannot do that with a single set of sources, because it breaks provisioning. When a user is added to a source, there is no way to determine which account type to create (A vs. B). You need a second source, which means you also need a second set of roles, etc.
Therefore, the options I see are double all sources and roles, or double the identities.
@I am supporting @udayputta If managing a delimiter file becomes too cumbersome, another option is to create a custom database and configure SailPoint to read data from it periodically.
You must clearly distinguish between
AD accounts used to define identities (authoritative accounts)
AD accounts created/provisioned as access for those identities).