
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-30-2022 03:11 AM
Hi everyone, we are using Azure Active Directory (AAD) for user and group provisioning and for SSO for our instance.
Multiple clients has their own SSO sources (Multi-Provider SSO > Identity Providers and there we have a few) (e.g. Company1 uses their SSO provider, Company2 uses their another SSO Provider) to login into 1 ServiceNow instance (with CSM and DS plugins). So all our customers provisioned to instance from different AADs, and all of them can use their own SSO.
In order system can understand which SSO should be triggered for specific user - there is OOB sso_source field which being populated from Company record, Company in order has OOB field sso_source which stores sys_id of correct SSO provider which should be presented for this specific user.
After the clone (and we do clone of Companies, because as we have CSM, we might have new customer which we created recently in prod, and we want to see him after clone in dev). Azure Active Directory allow to have only 1 SNOW instance per 1 SSO provider record (sso_properties table), so we can't have 1 AAD SSO for dev+uat+prod. We have to register 3 integration accounts in Azure for each company, they have different sys_id's and it's actually different records, so after the clone we are loosing correct value of SSO source for specific instance in each Company record. And we have to go and update all sso_source fields in all Companies, to set specific sso_source for dev/uat.
What is the best practice to automate it ?
I have this idea, but not sure if it's a best practice:
Create some table (u_post_clone) and have in this table 2 columns : Instance (values : DEV/UAT/PROD) ; Client (Client1, Client 2, etc) ; SSO Source. And create a post clone fix to query this table by instance, then for each Client go and query core_company and update SSO source to correct SSO source from this mapping table (u_post_clone).
Regards.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-04-2022 09:22 AM
Ok, I found an answers. So how we solved this:
We have 3 client. For each of them we created 1 AAD application integration.
First we added additional attributes to client AAD provisioning such as Company (hardcoded Name, and pointed to Company field in SNOW, name should be same string, after provisioning it will be automatically converted to reference, so we will receive the company directly from AAD), sys_class_name=customer_contact - for those accounts which we want to provision into Customer_contact table, instead of Sys_user, sso_source=sys_id of identity provider which created (for each of clients it's own indentity provider sys_id) - this allow us to do not run anything additional, all users will have correct SSO source from AAD.
For each of integrations we added in AAD authorized URLS which can access this application (for SSO perspective), so SSO can be reached now from DEV/TEST/PROD.
Then we cloned XMLs of created in PROD identity providers (we are using this sys_ids as in user records in sso_source field for each user, so after the clone we will not have run any scripts to replace this sys_id in dev/test. Then we changed the URLS in XMLs of Identity Providers (all the same just change instance URLs to point dev/test).
Regards.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-04-2022 09:22 AM
Ok, I found an answers. So how we solved this:
We have 3 client. For each of them we created 1 AAD application integration.
First we added additional attributes to client AAD provisioning such as Company (hardcoded Name, and pointed to Company field in SNOW, name should be same string, after provisioning it will be automatically converted to reference, so we will receive the company directly from AAD), sys_class_name=customer_contact - for those accounts which we want to provision into Customer_contact table, instead of Sys_user, sso_source=sys_id of identity provider which created (for each of clients it's own indentity provider sys_id) - this allow us to do not run anything additional, all users will have correct SSO source from AAD.
For each of integrations we added in AAD authorized URLS which can access this application (for SSO perspective), so SSO can be reached now from DEV/TEST/PROD.
Then we cloned XMLs of created in PROD identity providers (we are using this sys_ids as in user records in sso_source field for each user, so after the clone we will not have run any scripts to replace this sys_id in dev/test. Then we changed the URLS in XMLs of Identity Providers (all the same just change instance URLs to point dev/test).
Regards.