The Single Sign On facility allows another application to control user access to ExtraView. When this is enabled through ExtraView\u2019s behavior settings (see above), the SSO application is entirely responsible for the authentication of each user. Once the authentication is complete, the SSO application forwards the authenticated information to ExtraView, and ExtraView automatically signs on the user. If necessary, and subject to any licensing restrictions, a new user will be created within ExtraView.<\/p>\n
When ExtraView is configured to use SSO as the user authentication mechanism, the user points their browser to the SSO sign on page. ExtraView extracts the user ID and other pertinent data from the HTTP request header and automatically logs the user into ExtraView \u2013 no ExtraView sign on page is displayed. During the sign on process, ExtraView will access all of the user\u2019s information in the LDAP Server, assuming this is configured. A new ExtraView user will be created, if the user does not exist. If the user exists in the ExtraView database, their record is updated to ensure synchronization with the LDAP server.<\/p>\n
SSO Header Mapping<\/h3>\n
The \u201clogin\u201d HTTP header from SSO contains the authenticated user\u2019s information. ExtraView administrative data held in the security_user table defines the headers that are used by ExtraView and where in ExtraView each field is stored. All of these fields map to the individual fields that contain user data. This mapping is used in conjunction with the LDAP user data, bypassing the need for an administrator to add a new user specifying this information.<\/p>\n
In the ExtraView configuration file (Configuration.properties<\/span>), these fields are mapped to match the host header data as shown in the following example:<\/p>\n
As well as the fields such as USER_NAME and CITY in the example above, you can also map the user defined fields in the ExtraView security_user table. There are five of those, named USER_FIELD_1 through USER_FIELD_5.<\/p>\n
Notes:<\/strong><\/p>\n\n
If SSO_COMPANYNAME is configured AND it has a non-blank value in the header, it will always use that in creating\/updating the user<\/li>\n
If SSO_COMPANYNAME is not configured or it has a null\/blank value in the header, the app default COMPANY_NAME will be used to create\/update the user<\/li>\n
The user’s company name is not used to compare the existing user with the request to sign on a user<\/li>\n
If the SSO_UPSERT behavior setting is set to a value of YES, then the setting LDAP_UPSERT should always be set to a value of NO<\/li>\n<\/ol>\n
The SSO_DN_USER_ID_ATTRIBUTE<\/h3>\n
SSO_DN_USER_ID_ATTRIBUTE<\/span> – short for Distinguished Name User ID Attribute – indicates two behaviors:<\/p>\n\n
The SSO header is in Distinguished Name format, e.g., cn=abc,dn=def,ou=ghi<\/span><\/li>\n
The attribute of the user ID within the DN is the value of the SSO_DN_USER_ID_ATTRIBUTE followed by an optional instance number.. For example, if SSO_DN_USER_ID_ATTRIBUTE=cn, then the user ID would be abc<\/span> based on the example in the previous point.<\/li>\n<\/ol>\n
then the SSO_DN_USER_ID_ATTRIBUTE=cn#2<\/span> would establish the 2055092<\/span> as the user_id<\/span> (the #2<\/span> indicates that the second instance of the attribute should be used). Note that cn#1<\/span> and cn<\/span> act the same when used as configuration values for SSO_DN_USER_ID_ATTRIBUTE.<\/p>\n\n\n
<\/p>\n\n\n\n
SSO with Microsoft Azure Configuration<\/h3>\n\n\n\n
This section provides an example of SSO application configuration in Microsoft Azure and instructions on configuring ExtraView SSO to work with Azure SAML:<\/p>\n\n\n\n
Before Creating the Azure SAML Enterprise Application – collect these two pieces of information:<\/p>\n\n\n\n
1) The ExtraView sign on URL – this is the URL that users access to get to the ExtraView sign on screen<\/p>\n\n\n\n
e.g. https:\/\/mydomain.net\/evj\/ExtraView<\/p>\n\n\n\n
2) The ExtraView Consumer servlet URL – this is a URL that needs to be configured as a new JkMount point within your Apache configuration file<\/p>\n\n\n\n
Find:<\/p>\n\n\n\n
JkMount \/evj\/ExtraView\/* tomcat1<\/p>\n\n\n\n
Add a new line:<\/p>\n\n\n\n
JkMount \/evj\/Consumer tomcat1<\/p>\n\n\n\n
Now create your SAML Enterprise Application and configure it to authorize the set of users who are authorized to sign on to ExtraView.<\/p>\n\n\n\n
Next, in Section 1 place the ExtraView sign on URL\u00a0 in the Sign on URL<\/strong> parameter and place the ExtraView Consumer servlet URL as the Reply URL (Assertion Consumer Service URL)<\/strong> parameter.<\/p>\n\n\n\n
In Section 2, identify the attributes and claims that Azure will include in the IDP response. These will be mapped in the ExtraView Configuration.properties file to user account profile information.<\/p>\n\n\n\n
At a minimum, you must map the user’s unique login id and capture the Claim name for that value. This allows ExtraView to know which account the user is signing on with.<\/p>\n\n\n\n
If you are configuring SSO_UPSERT=YES to create or update user accounts automatically, you will need to map additional attributes – at minimum, you will additionally need First Name, Last name, and Email address to create a new user account in ExtraView<\/p>\n\n\n\n
Note that you need to copy the Claim name<\/strong> value for each attribute.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\n