I need to use the Access Request API to add Entitlements from multiple sources to an identity from a different source. A colleague is telling me that it will not work, that all of the Entitlements’ sources have to match the source on the Identity, but that doesn’t make sense. Of course all of the Entitlements are going to be being pulled from various sources. Is there truly a limitation that would prevent me from using the Access Request API to add these Identity (requestedFor) / Entitlement relationships?
The standard process would be like this:
- New employee is created in HR
- HR source is aggregated and picks up the new employee record.
- The HR source is associated to an HR Identity Profile. This will identify that the new employee needs an identity and will create the identity.
For accounts and entitlements, you can:
- Access Profiles associated with Lifecycle states: For example, you can have an AD access profile to setup the base AD account and add default group memberships. Once the access profile is assigned, the account will be created and the entitlements will be added.
- Roles with membership criteria: If the new identity meets the criteria for the role, the associated access profile or entitlements are assigned (an account in the target system is created.)
- Access Request: The user, manager, admin can go to the request catalog and select a role, application/access profile, or entitlement for the user. Once the request is completed/approved, the account would be created and the entitlements assigned.
You can use the Access Request API to automate the process for option 3. Some customers might use this if they already have another access request portal that they want to integrate with ISC. However, your colleague is right in that the entitlements you are requesting have to be targeted to a specific source. In ISC, when you setup a source and aggregate the entitlements, those entitlements are linked to that source. There is not a generic list. For example, many databases might have a DBA role. For ISC to be able to provision the DBA role, I first have to set up each target database and aggregate its entitlements. Then I will need to request Database1:DBA, Database 2:DBA, Database 3: DBA, Database 4:DBA.
Does that make sense or is your use case different?
Hi @treycarroll
Welcome to SailPoint Developer Community.
Yes, This doesn’t make any sense.
You can create identity from any Source, it can be HR source sometimes it can be a target source.
You can have entitlements on all the sources, even we do have entitlements on HR source as well.
An Identity can have access on any source, that means you can add entitlements from any source, then Identity will get access to that source.
Thanks
Krish
2 Likes
If this was true then IAM would not exist 
2 Likes
Thank you for the detailed reply, Alicia! I’m reading through this slowly and comparing it with the internal communications from my SailPoint consultant. It’s seeming like he’s just plain wrong. I think that what I need to do is just submit the Access Requests for Entitlements from various source against the Identity ID (in the requestedFor parameter) from the main (HR) source, and just prove to him that it works.
Good feedback, Nitesh. Thank you.
Thank you for confirming, Krishna. This is very helpful.
Hi Alicia,
Thank you so much for the detailed reply. You’re spot on.
I’m attempting to call in an access request from a catalog request in a different platform. Everything is working well, but now I have learned that “Secondary accounts” (just a user object with a special attribute value) are being pulled into a separate source. Our Entitlements are all in a (primary) AD source right now.
When I use postman to create an access request where the requestedFor is the Identity ID from that Secondary AD source and an Entitlement from a different AD Source I’m seeing the following:
- The request goes through smoothly as SailPoint returns a 202.
- When I inspect events I can watch the access request fail. The error message says that there is a configuration issue with the IQService: “IQService must be configured correctly to perform provisioning operations.”
My colleagues on the IAM team believe that SailPoint will never (should never) allow the access request because it entails an Identity ID from the 2ndary AD source and an Entitlement from the Primary AD Source. But ambassadors on this thread seem to disagree, and I have been able to experiment and prove that SailPoint has no issue with allowing Entitlements from different sources to be connected to an Identity ID from a different source. (Our Identities come from an HR source, not from either of the AD sources.)
Could it be that that 2ndary AD source just requires some type of configuration?
Thank you for your help.
Trey Carroll
Are your two AD domains in a forest or do your users have separate accounts in each AD domain? How many AD sources do you have in ISC?
Hi Alicia,
There are separate domains for Sandbox an Prod, but really all of the Entitlements are being pulled from one AD Domain. The problem seems to be coming from this SailPoint team’s decision to pull Secondary accounts (just an AD User object with a custom attribute set to True) into a separate source. These guys are telling me that those are going to create separate Identities. (Main Identities for normal users come from the HR source.) I was able to find 1 Identity that was from that AD Secondary Account source. Even though this Identity comes from the same AD domain where the Entitlements “live”, a REST API Access Request that had the that Secondary Account source’s Identity ID in the requestedFor parameter (and an Entitlement ID from the main AD Source), SailPoint accepted it with a 202, but then could not process it, saying that “IQService must be configured correctly to perform provisioning operations.” I’m trying to learn to understand, to communicate with these guys. We absolutely have to be able to give these AD secondary accounts Entitlements. In AD we would just be adding them to the groups so that they could access fileshares, access distribution lists, etc. I’m confused about why this would be impossible in SailPoint. I kind of get how these secondary accounts have to be Identities from a separate source (since they don’t start through an HR onboarding process), but that can’t mean that they can never receive access from our normal AD Entitlements. These guys are telling me that I have to duplicate tens of thousands of Entitlements into the Secondary Account source- for a small number of these secondary accounts. That just doesn’t seem right - but I am inexperienced with SailPoint, thus your expertise is invaluable. Do they just need to fix configuration on that Secondary Account source (as the error message implies) and it will work?
Regards,
Trey Carroll
If you look up the person whose Identity comes from the AD Secondary accounts source, do they have one from the AD secondary accounts source or two (one from the secondary source and one from the AD source with the other users?
Alicia
Just one - the one from the Secondary source.
OK I think I understand what you are trying to do.
You will need to use the entitlement associated with the secondary source. Is there a reason that you don’t want to run the entitlement aggregation for the secondary source?
Hi Alicia,
Sincere thanks for the reply.
There aren’t any entitlements for that secondary source. All of the Entitlements are on the main AD source.
I’m confused about why we would choose to put these Secondary accounts (just user object with a special attribute marking them as “secondary”) on this separate source - where they can never receive normal access via the established Entitlements from the main source? Isn’t that counter productive? Are these becoming Accounts or Identities? They can’t come from the HR source, but shouldn’t they be defined on the main AD source where the Entitlements come from?
The reason that we created these AD secondary accounts is to give the users who own them access to things is special ways; so, making it so that these new accounts | identities can’t ever receive any of the established entitlements confuses me.
The replies at the beginning of the thread made it seem like I had asked a silly question. There were several replies similar to: “of course you can give entitlements from different sources to an Identity from a different source”. I guess I’m just really confused now, because you seem to be saying that it’s not possible after all.
It seems like everyone who would ever pull in Secondary accounts into a different source would have this problem. Surely other organizations have run into this same scenario. Secondary accounts have to be able to receive entitlements. True? What is the standard solution? Create copies of Entitlements from the primary source in the Secondary source? That seems like a poor solution. Is it standard?
Thank you,
Trey Carroll
When you are creating an access-request body, you are not just asking for an entitlement by a “name”. The body has the entitlement id number which has meta data stored in SailPoint that associates it with the source. If you use the entitlement id from the OneDS source, you will be creating a request for the OneDS source, not the OneDS - Secondary source. Yes, both the OneDS and OneDS - Secondary source represent the same target system but internally to SailPoint, they are different.
Thank you so much, Alicia. I’m feeling like I’m still missing something here. I understand what you’re saying but it just seems like there’s still some point of confusion that’s causing the experts to give conflicting answers. I have experienced SailPoint consultants on my project meeting with project leadership telling them that this is possible, that I’m unnecessarily raising this as an issue, that these Identities created from the Secondary source will have no issues with receiving Entitlements from the AD source.
The ordinary employee Identities are going to be coming from the HR System, so the source is going to be something like “SAP Success Factors”.
The Entitlements, on the other hand, are going to be pulled from AD, so they’re going to be coming from a Source like “Active Directory - OneDirectory”.
So, clearly even the most basic, normal Access Request for one of these HR Identities is going to involve an access-request body that contains an Identity ID from the HR Source and an Entitlement from the AD Source… which seems to break the rule that “Access Requests for an Entitlement from Source B cannot be created for an Account under an Identity ID from Source A.” that you seem to be stating.
Are the rules different when the Identity ID is coming from a primary source like the HR Source?
Also, some of the initial response on this thread (from much less senior ambassadors than yourself) seemed to indicate that it was routine to do this, that my question was actually silly.
Thanks again,
Trey Carroll
You seem to be overusing the word “identity” here which is causing confusion. An “Identity” is effectively a person. Identities have accounts linked to them. Identities can have accounts on many sources. Each account can only have entitlements from its own source.
If you have identities based on Active Directory accounts from source AD1, then you could assign them entitlements from source AD2 - however that would involve creating an account on AD2 and linking it to your identity. If you want to grant accounts from AD1 entitlements from AD2, then you need to expand the scope of your entitlement aggregations on source AD1 so the entitlements appear associated with that source.
This is only confusing when you have multiple sources pointing to the same domain. You’d never even think that you could add SAP roles to an AD account without creating an account on the SAP source.
Thanks, Kevin. I have edited my original post to remove the wording that implied that access would be given to the Identity rather than the underlying Account. (I just got used to thinking of it that way because the Access-Request API call requires an Identity ID, rather than an Account ID.)
@gigisherer1 @gigisherer @tranetechnologies Any thoughts?