The Single Sign On facility allows another application to control user access to ExtraView. When this is enabled through ExtraView’s 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.
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 – no ExtraView sign on page is displayed. During the sign on process, ExtraView will access all of the user’s 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.
SSO Header Mapping
The “login” HTTP header from SSO contains the authenticated user’s 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.
In the ExtraView configuration file (Configuration.properties), these fields are mapped to match the host header data as shown in the following example:
| ############################# ## SSO HEADER MAPPING ## ############################# SSO_PRIMARYKEY = USER_NAME SSO_SURNAME = SURNAME SSO_GIVENNAME = GIVEN_NAME SSO_EMAIL = EMAIL_ADDRESS SSO_STREET = STREET SSO_CITY = CITY SSO_STATE = STATE SSO_POSTALCODE = POSTALCODE SSO_COUNTRY = COUNTRY SSO_PHONE = TELEPHONE_NUMBER SSO_MOBILE = MOBILE_NUMBER SSO_PAGER = PAGER_NUMBER SSO_COMPANYNAME = COMPANYNAME |
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.
Notes:
- 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
- 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
- The user’s company name is not used to compare the existing user with the request to sign on a user
- 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
The SSO_DN_USER_ID_ATTRIBUTE
SSO_DN_USER_ID_ATTRIBUTE – short for Distinguished Name User ID Attribute – indicates two behaviors:
- The SSO header is in Distinguished Name format, e.g., cn=abc,dn=def,ou=ghi
- 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 based on the example in the previous point.
Another example is:
cn=2055092,cn=Users,dc=dsd,dc=fmcna,dc=com
In this case, SSO_DN_USER_ID_ATTRIBUTE=cn would still work to establish 2055092 as the user_id.
If the DN is:
cn=Users,cn= 2055092,dc=dsd,dc=fmcna,dc=com
then the SSO_DN_USER_ID_ATTRIBUTE=cn#2 would establish the 2055092 as the user_id (the #2 indicates that the second instance of the attribute should be used). Note that cn#1 and cn act the same when used as configuration values for SSO_DN_USER_ID_ATTRIBUTE.
SSO with Microsoft Azure Configuration
This section provides an example of SSO application configuration in Microsoft Azure and instructions on configuring ExtraView SSO to work with Azure SAML:
Before Creating the Azure SAML Enterprise Application – collect these two pieces of information:
1) The ExtraView sign on URL – this is the URL that users access to get to the ExtraView sign on screen
e.g. https://mydomain.net/evj/ExtraView
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
Find:
JkMount /evj/ExtraView/* tomcat1
Add a new line:
JkMount /evj/Consumer tomcat1
Now create your SAML Enterprise Application and configure it to authorize the set of users who are authorized to sign on to ExtraView.
Next, in Section 1 place the ExtraView sign on URL in the Sign on URL parameter and place the ExtraView Consumer servlet URL as the Reply URL (Assertion Consumer Service URL) parameter.
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.
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.
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
Note that you need to copy the Claim name value for each attribute.
In the ExtraView Configuration.properties file, locate the SSO section and map the SSO_xxx parameters to the claim names:
########################
## SSO HEADER MAPPING ##
########################
SSO_PRIMARYKEY = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
SSO_SURNAME = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
SSO_GIVENNAME = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
SSO_EMAIL =http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
In Section 3 – download the Base64 encoded version of the certificate
In ExtraView, navigate to Admin –> Advanced –> Encryption Key Management
Add a new entry – the key name is spkey and the value will be the certificate text – including the —–BEGIN CERTIFICATE—- and ——END CERTIFICATE—– parts/
In Section 4, copy the Login URL and Azure AD identifier strings
In ExtraView go to Admin –> Site Configuration –> Behavior Settings
Edit SAML_SSO_SERVICE and paste in the Sign on URL string
Edit SAML_SSO_SP_ENTITY_ID and paste in the Azure AD identifier string
Edit SAML_ASSERTION_CONSUMER_URL – this is going to be the URL to your instance with /Consumer at the end
e.g. https://myserver.mydomain.com/evj/Consumer
Edit SSO_DEFAULT_AREA, SSO_DEFAULT_PROJECT, and DEFAULT_USER_ROLE – pick values that you want to be used when creating users
Edit SSO_SIGNOFF_REDIRECT_URL – set this to the URL of a web page where you want users to be sent to, when they hit the “Sign Off” button in ExtraView
Edit SSO_STATE – set the value to SAML
Stop and restart the Tomcat application server to pick up the changes.
When you go to the ExtraView URL, you should be prompted with an Azure login, and then be taken directly into ExtraView.
If you have any issues and need to by pass the SSO login to get into ExtraView and make administration changes – you can append ?EV_BYPASS_SSO=YES to your URL to get back to the standard ExtraView login page
For example: