Hi Mitchell,
SSO is usually about having third party applications and websites using some protocol, like LDAP, to use your central Active Directory database of credentials. Active Directory usually contains user's accounts for your own employees (internal and external). It needs to be centralised, and highly secured.
For Vendor Risk Management you don't need to manage external third party's users (aka Vendor Contacts). You don't want to administrate the Vendor Contacts yourself. You only define at least one Primary Contact for a Vendor in ServiceNow, then you let him add/remove/manage additional Contacts. It should not your responsibility to do that, because you have no way to know when a Contact will join/leave its position. No Vendor Contacts will ever be able to log in any of your other systems, nor do anything else in your ServiceNow instance. Vendor Contacts are not stored in same table as other users.
Using SSO for GRC Vendor Risk Management would only be useful for your own employees (aka Users), and those don't use the Vendor Assessment Portal. Users with Internal Vendor Risk Management roles, like the one who assess the vendors (vendor risk assessors or reviewers) or create templates and schedules (vendor risk managers). For that, they would not use the Vendor Assessment Portal, but the platform backend, ideally using a SSO linked to your Active Directory.
This is why any SSO configuration is de-activated by default for the Vendor Assessment Portal!
Having Vendor Contacts using SSO would only make sense if it was connected to the vendor's SSO instead of your own. Is that what you would like to achieve, having specific SSO configurations for each vendor that you manage?
∴
Best regards from Switzerland
Shiva :¬,
If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.
