Ability to assign limited “View Only” access to configuration settings via configuration hub! Production rollout during week of March-11th.
We have implemented granular permissions to all the configuration hub actions and can now provide granular access based on customer requests, by creating new user levels, with least privilege access for specific configuration hub capabilities.
The additional user levels can be granted in addition other user levels, in order to provide the necessary access level to configuration hub without the need to have full Admin user level (org_admin)
What is the Problem?
When we first launched Configuration Hub, only users with IdentityNow Admin user level (org_admin) could access configuration hub.
Any Admin could access any of the available actions in configuration hub, including: creating backups, migrate configuration between tenants & deploy configuration changes.
What is the Solution?
Admins can now use the Identity UI “Set User Level” to assign configuration Hub user levels.
Three new user levels are available to grant access to configuration hub:
Configuration Hub Admin - permissions to view and perform any action in Configuration Hub.
Configuration Hub Backup Admin - permissions to manage backups which includes Create backup, Delete backup, View backup summary and details, View existing drafts and Activity Logs.
Configuration Hub Reader - View only permissions which includes View backup summary and details, View existing drafts and Activity Logs.
Nice @yael_kadoshi!
I missed the announcements on the Configuration Hub, so thanks for posting this because thanks to you I discovered this new neat feature!
I have a few questions about the Configuration Hub itself and I’m not sure if you’re the PM for that feature or is someone else (if it’s not you, can you connect me with its PM?)
The documentation is a bit limited to a sort of “SOP” on how to create and work with objects in this new space. I searched for courses or quick learnings in the University and I couldn’t find any… can you point me to any demos and/or best practices document on how/when to create a backup before changing things in the platform?
Scenarios I’m interested in learning more:
Best practices to create a backup before implementing a change as part of the change management process.
What settings will not be covered by a backup?
Can we connect Sandbox with Prod to test new configurations in Sandbox and then promote them to Prod?
If the above is possible, can we promote partial configurations or is it required to have mirrored tenants to deploy configurations across environments?
You can find the list of the supported configuration settings linked from the product documentation - all objects in the list (backup and deploy are the config hub actions) SaaS Configuration | SailPoint Developer Community
You can create backups and migrate them between your tenants by creating connections from the tenant that you would like to deploy to (target tenant) to the tenant that has the desired config backup (source tenant).
You can create a partial backup with only specific objects types, or even specify list of exact names of specific objects.
When you create a draft from a selected backup of connected tenant, you can still pick and choose specific object types, select specific objects or even modify object configuration if needed, prior to deploy.
For example, you can create partial backup in sandbox with only access profiles, roles and gov groups. You can connect from prod to sandbox and create a draft from that sandbox backup. The draft will compare the configuration from the selected sandbox backup to the prod configuration (the ‘live’ config of the tenant you logged into) and will display the differences. You can edit the draft, check/uncheck objects, modify and adjust the configuration as needed and then deploy it to production.
You can use the object mapping feature, to define value substitution and map object names if for example you have different naming between sandbox and prod.
NOTE: currently we do not backup / deploy secrets and therefore, do not support tokenization of the secret with the object mapping feature.
For example: When you migrate new source from sandbox to prod for the first time (source name does not exist in prod), after deploying the new source in prod, you will need to use identityNow to configure the credentials. When the source already exist, config hub will not override credentials of existing source, for example, if you will modify source in sandbox and migrate the changes to prod, the credentials of the prod source will retain.
Hi @yael_kadoshi,
where are these new user levels stored in terms of entitlement? I was able to retrieve the list of IDN rights via this search: “source.name.exact:IdentityNow” but the new rights: “sp:ui-config-hub[*]” don’t appear.
Thanks !
Thanks for the feedback. Im checking about the entitlements for the legacy user levels. As far as I’m aware, these are. It used and not updated for any of the newer user levels.
The granular rights for the user levels are managed within the platform Authorization service and currently not accessible.
Can you provide more details about how / hat for you use the list of IDN rights that you retrieve via this search: “source.name.exact:IdentityNow”
We don’t yet have a public API to return the available list of user levels (AKA capabilities). The search query you referenced will just return the user levels specific to IdentityNow, as described here: User Level Matrix - SailPoint Identity Services.
We have an engineering ticket in the backlog (PLTIN-6296) to provide a public endpoint for fetching the full list of user levels available in Identity Security Cloud. In the meantime, you can refer to this endpoint documentation to know what other capabilities (AKA user levels) are available in ISC. get-auth-user | SailPoint Developer Community. Scroll down to the bottom to see the capabilities enum. This list is manually updated, so it may lag behind as new user levels are added. You can also programmatically set user levels using patch-auth-user | SailPoint Developer Community.
Hello,
thank you for your answers. We use this search in a loopback connector to manage IDN/ISC rights.
I don’t think we’re going to give this kind of right to identities other than the team’s yet. So I’ll wait for @colin_mckibben the ticket to update everything.
Thanks again
Ability to assign limited “View Only” access to configuration settings via configuration hub! Production rollout during week of March-11th.
