SSO Connections

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:

  1. 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
  2. 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
  3. The user's company name is not used to compare the existing user with the request to sign on a user
  4. 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:

  1. The SSO header is in Distinguished Name format, e.g., cn=abc,dn=def,ou=ghi
  2. 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.