Introducing the new SailPoint Identity Security Cloud Governance (SaaS) connector within the Identity Security Cloud. This connector recognizes the Identity Security Cloud as a governed system, handling identities as “Accounts”. Additionally, it oversees user levels (permissions), roles, and governance groups as entitlements. Simplifying access requests and reviews, the access model of the Identity Security Cloud Governance connector streamlines the process.
We are thrilled to announce the launch of the new SailPoint Identity Security Cloud Governance (SaaS) connector within the Identity Security Cloud.
This connector treats the Identity Security Cloud as a governed system, handling identities as “Accounts”. Additionally, it oversees user levels (permissions), roles, and governance groups as entitlements. Simplifying access requests and reviews, the access model of the Identity Security Cloud Governance connector streamlines the process.
This is a SaaS Connector that works for your Identity Security Cloud tenant.
What is the Problem?
There is no way to manage access request and access reviews for Identities effectively in Identity Security Cloud.
What is the Solution?
The SailPoint Identity Security Cloud Governance SaaS connector provides a deep level of governance and access management capabilities for the Identities present within the Identity Security Cloud tenant. It manages identities as accounts, and user levels (permissions), roles, and governance groups as entitlements.
High-Level Capabilities
Account Management
Manages Identity Security Cloud Identities as Accounts
Aggregate and Refresh Accounts
Full Account Aggregation
Single Account Aggregation
Account Aggregation Filters
Create Accounts
Enable/Disable Accounts
Add or Remove Entitlements
Access Certification
Entitlement Management
Manages Identity Security Cloud Roles, Governance Groups and User levels (Permissions) as Entitlements
Aggregation
Entitlement Aggregation Filters (For Roles and Governance Groups Aggregation)
NOTE -
If you want to use only a specific entitlement (for example, User levels), then you can remove the other entitlement attribute from account schema and remove the specific entitlement schema object.
What would be the benefit for having Roles as an entitlement on this source? I am coming from using colab-saas-conn-identitynow-management, so familiar with how it manages accounts, user levels, and governance groups. But the Role piece is new.
Given that everyone already “has” an IdentityNow account associated with the identities, why do we need to configure a brand-new source instead of having the ability of “editing” the existing IdentityNow source?
We have ~30K identities and at most 1% will need some level of admin rights, so although I see the value of managing User Levels via roles and access profiles that we can include in birthright, approval and certification processes, I feel it’s overkilling the need of configuring a whole connector from scratch.
Also, if IdentityNow will become a source, what would be the impact of the account schema of that source to configured mappings in the identity profile?
Will we have to add IdentityNow to the lifecycle automations in Provisioning, so we revoke admin rights when someone leaves? What would be the effect of the new Identity State flag in the status of these accounts?
We considered the “Roles” based on the feedback from few of our customers where customer wants the visibility for the associated Roles as a part of the entitlements for the accounts.
I agree that it might not be required for everyone and ‘just in case’ kind of deal. If it is not required for your use cases and requirement, it can be removed from the account schema (Roles) and as well as from the Group attributes.
Similarly, for other types of entitlements. We have some feedback where customer wants to manage only User Levels, so in that case they can keep only User Levels as entitlements. We tried to provide all the flexibilities within the same connector so that it can be easily configured based on the specific requirement.
This connector provides loopback capability and instead of using the custom connector or colab connector, customers can utilize this OOTB connector as per the requirement.
It is not like that, everyone should use it and follow the same access model. The requirement varies from customer to customer. We kept basic minimal attributes as a part of the account details.
There is no impact in terms of mapping as Identities are already created from your authoritative sources. There is no need to create an Identity Profile for this source. There is no other impact of it within the Identity Security Cloud.
Hi @jrossicare, can you please check whether you defined the correlation configuration correctly.
For example, account attribute “Email” set to Identity attribute “Work Email” and similarly you can use other attributes and set the correlation configuration prior to performing aggregation operation.
If there is any other concern or query, feel free to raise a support ticket.
Hi @jrossicare, ideally if the account attribute “id” is mapped in the correlation configuration, accounts should be correlated. Since this is a SaaS connector, there is no default correlation rule can be provided as of now; for which we are working on an enhancement item.
In case, you already added the attribute under correlation configuration and still there is any issue with the correlation, then there might be other reason as well which I am not sure and might require detail investigation. I would suggest to raise a support ticket. Thank you.
I think it is a huge miss that this connector relies on a personal access token for authentication and an API key that is not bound to a specific user’s identity cannot be utilized instead.
Hi @jmutschlerProtiviti, it is not a miss that connector uses Personal Access Token for authentication. We have many customers who are already using a custom connector for achieving this via PAT and this is a requirement that we received as per the feedback. However, there will be also subsequent enhancement in this connector for the authentication mechanism and you will get more flexibility in terms of authentication. Thanks!
Thanks @dinesh_mishra, can you share any details about the planned enhancements to the authentication mechanisms? As this is implemented currently with PAT based authentication my main concern is with the connector failing if the administrator whose PAT was used leaves the organization.
I saw some threads about that, but those were workarounds that teams had to implement to manage user level accesses via same processes their organizations had (e.g. approval process, birthright rules, cert campaigns, etc). It’s great to see that SailPoint is making some efforts to offer that OOB, and don’t get me wrong, we need this too for when we expand SailPoint access to other teams, but my concerns are around the need of setting a new connector up.
Given that “IdentityNow” is already a source bound to the identities created out of the authoritative source, I feel like we just needed some “edit rights” on that very source and limit some components in the “Edit Source” page only to things that we should be really modifying and not everything in a source (especially “account attributes” are usually mastered from authoritative source via Identity Profile mappings, so why this is even included in this source?)
I can see the use of creating new accounts, enabling and disabling them in this source would benefit us on the long term as an alternative to upload separate CSV sources, but this new connector adds a layer of complexity that seems unnecessary.
From your answers in the thread I also see this needs to evolve a bit as some correlation needs to be improved (I agree with @jrossicare: why do we need to correlate these accounts in the first place? don’t they map 1:1 with the identities already in the source?), so we’ll see how this connector evolves before messing with our accounts in our Sandbox which we actively use to explore our implementations before even consider them to deploy in Prod.
Thanks for the announcement though, I’ll keep watching your updates.
Hi @jmutschlerProtiviti and @eabedrapo1, now we added the uid (primary account ID) attribute in the account schema as a default schema attribute.
There is no functional changes and still it works in case you add this attribute manually. If you already created a source, I would suggest to add this attribute manually in the account schema and perform account aggregation again. This should resolve your concern for correlation. If still there is any issue for account correlation as per the earlier suggested steps, then please raise a support ticket.
Hi @jmutschlerProtiviti, I understand your concern here; however this is the current way that it requires a PAT and you can use the client ID, client secret along with the provided scopes. We are actively exploring alternative methods and extending support for other grant types. This initiative is currently in the research and development phase.
There will be more updates to it in the near future. Thank you.
The full aggregation time is ~6-10x that of colab-saas-conn-identitynow-management. Is the source aggregating Roles even if the roles schema has been removed?
Hi @eabedrapo1, I understand your concern. Basically, if someone is not interested to manage any entitlements, they can skip/remove that and similarly if the functionality can be achieved via any other ways based on specific requirement, it is not required to go via this connector route. Nevertheless, a considerable number of customers have communicated their challenges and scenarios to us, leading to the development of this connector.
I appreciate your feedback. Regarding the suggestion you mentioned, I recommend opening an idea in our idea portal.
Correlation is not an issue for this connector and I mentioned some ways to do that in my earlier comment.
Now in addition to that you can add uid as an account schema attribute and I think that should resolve the concern if there is any. If still there is any specific issue, I would suggest to raise a support ticket.
Introducing the new SailPoint Identity Security Cloud Governance (SaaS) connector within the Identity Security Cloud. This connector recognizes the Identity Security Cloud as a governed system, handling identities as “Accounts”. Additionally, it oversees user levels (permissions), roles, and governance groups as entitlements. Simplifying access requests and reviews, the access model of the Identity Security Cloud Governance connector streamlines the process.
