Single Sign-On (SSO) allows users in your organization to use OnCommand Insight without needing a special account.
Administrators can configure the OnCommand Insight Server for Single Sign-On (SSO) access for users in their corporate domain. With SSO configured, any user with the domain email address can log into Insight using their corporate credentials. OnCommand Insight supports the OpenID Connect (OIDC) protocol for SSO.
Note: SSO is available for the Insight Server web-based UI only. SSO is not available for Data Warehouse, Reporting, or Java Client UI components.
Steps to Configure SSO
- Navigate to
- Enter the SSO configuration URL to auto-populate the configuration fields (also called "OpenId-configuration"). This is a URI that provides a JSON describing an identity provider's configuration.
- Alternatively, enter the SSO configuration URLs manually for the following identity provider resources. Links to more information about these resources can be found in the Related Information section at the bottom of this page.
- Authorization endpoint: An identity provider resource that prompts the user for credentials. Upon success the identity issues an authorization grant to OnCommand Insight that allows it perform actions on the user's behalf.
- JWK Set URI: Provides the public keys used to sign the JWT tokens. This allows the client to verify that the JWT tokens were actually issued by the identity provider and not a third party.
- Token endpoint: Identity provider resource in which the client trades its authorization grant for JWT tokens. The client must also provide the client id and client secret (see below). The JWT token that Insight uses is the "identity token", which indicates the username and roles of the user.
- End Session Endpoint: Provided by the identity provider which the client (OCI) causes the browser to redirect to, and in turn the identity provider invalidates the user's session with the identity provider. This means that at the next sign-on, the user will have to enter credentials.
- Client ID: Uniquely identifies the client (OCI) and differentiates it from the other clients known by the identity provider. The identity provider generates the client id when an application is created for it, and the client must know the client id, as it presents it as part of the token request.
- Client Secret: A random string known only to the identity provider and client that authenticates the client to the identity provider, proving that client is the application it claims to be and a not a malicious third party. Along with the client ID, the client secret is passed to the identity provider as part of the token request. The client secret is generated by the identity provider. With Azure Active Directory, multiple client secrets are allowed.
- JWT claim for username: The claim in the identity JWT token that identifies the user 's username. A claim is a key-value pair in the JSON payload of the JWT token. The "JTW claim for username" configured is the name of the key, and for each identity token, the value is the username of the user being authenticated. The key name may vary from identity provider to identity provider. For Azure Active Directory, the claim name will typically be "preferred_username".
- JWT claim for roles: Like above except that the value of this claim is a list of OCI roles, i.e. "guest", "user", "admin". For Azure Active Directory, this key is named "roles".
Manage SSL Certificates
You must import the root certificate of your identity provider’s SSL certificate chain. To do so, download the root certificate associated with the host name of the token endpoint. (login.microsoftonline.com for Azure Active Directory) and save it to a file. Then click the “Certificates” button and using the “Manual” tab, select the file and supply an alias such as “sso-root” to import it.”
If SSO is already enabled and you imported a new certificate, you must restart the SANScreen service.
Enabling SSO in the Operating System
To enable SSO on the current system as well as make the ssoAuth system property preserved through upgrade, you must do the following.
To enable SSO on Windows, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\NetApp\SANscreen in the registry. Change the value of ssoAuth from false to true. This value is read during upgrade and used to set the ssoAuth system property for the upgraded system. It has no effect on the current instance; you must also update ssoAuth in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\SANscreen Server\Parameters\Java Options.
To enable SSO on Linux, navigate to /opt/netapp/oci/conf/ and open file wildfly.properties. Change the value of SSO_AUTH_ENABLED from false to true.
After enabling SSO, restart the SANScreen service.
Troubleshooting SSO Problems
If you receive a "Not Authorized" error, check the server.log for details. You might see this error if Insight reports that authorization fails but the identity provider has authenticated the user properly.
In the event that users cannot log in with SSO, log in as a non-SSO user with Administrator permissions and correct the SSO configuration. You can do this by entering <Your Insight URL>/uiserver/login.html#
in a browser window.