Many organisations take advantage of Identity Providers to provide their users with a single account that they can use to log in to the various third-party cloud systems required to perform their job.
For example, a user may use the same account to log in to multiple systems such as Office 365, Salesforce, and Google Docs. When a user leaves the organisation, it is simple to kill access to all services by disabling a single account from within the SSO provider's admin portal.
SSO is provided using the OpenID Connect standard. In theory, any Identity Provider that adheres to this standard can be used; however, we have validated (and provided instructions) the following well-known providers:
Rules/tips for SSO user accounts
There are some special rules for SSO user accounts:
The e-mail address for the account must match the e-mail address of existing users within your organisation's Identity Provider.
Roles and permissions are still assigned when you add your users' accounts - your Identity Provider is only used to validate that your user is allowed access.
If you enable automated account management emails, the welcome email the user receives is slightly different. SSO users do not have to create a new password, as they will be logging in with their corporate SSO account instead.
Users who try to log in using SSO on older EdgeVis Clients (pre v9.1) will be rejected automatically, as these clients do not know how to contact your Identity Provider to verify a user's identity. These users must upgrade their clients first to continue.
Users who use different viewing clients (e.g. VMS Gateway or Milestone) should not use SSO accounts, as these do not know how to validate EdgeVis SSO users interactively. In this situation, it is ultimately the end VMS that should be performing identity checks on users accessing EdgeVis video.
When you delete a user from your Identity Provider you must manually tidy up their account on EdgeVis Server as well.
It is still possible to create non-SSO user accounts during account creation - it is highly recommended that at least one System Administrator account be non-SSO to ensure that you can still log in should there be an issue with your SSO provider.