You should not attempt to connect a Single Sign On server to ExtraView, until ExtraView has been installed stand-alone and you have verified its operation.
SSO with ExtraView is an optional setting that allows users to gain access to ExtraView without ever seeing the standard sign on page. The SSO software authenticates each user access and passes this information to ExtraView.
SSO software is available from third parties and organizations that have developed their own solutions. There are several products available. ExtraView is known to work with many of these products, but has not been tested with all. It should be possible to customize any SSO product with ExtraView, but this is dependent on the SSO software following standardized conventions. Netegrity from CA is an example of a popular SSO mechanism that is compatible with ExtraView.
To work, there is a Single Sign On software running in the same network space as ExtraView. ExtraView gives up authentication of the user ID and password to the SSO software. ExtraView then receives a request from the SSO software, specifying that the user has been authenticated and is therefore authorized to use ExtraView.
ExtraView needs to know who the authenticated user is, and this is achieved by the SSO software placing the User ID in the request header to ExtraView. Within ExtraView, the behavior setting named SSO_STATE is set to a value of YES. With this in place, ExtraView looks to see if the incoming request to sign on has the User ID within the request header. If this is present and is a valid user within the ExtraView database, the user is automatically signed on to ExtraView. No sign on screen is be seen by the user. For a full list of the behavior settings connected with SSO, see the page LDAP and SSO Behavior Settings. Also see the section on the Configuration.properties File in this guide for details on how to configure SSO correctly.
ExtraView customers may use their SSO software with ExtraView by configuring their SSO to work in this way and as further exemplified by the example that follows.
This can be customized further, for example by having ExtraView automatically create user accounts for User ID’s that it does not recognize in the request. If this functionality is required, pleas contact the ExtraView Professional Services team who will be pleased to help develop a specification for this, and to provide a quotation for the customization.
These are defined in the Configuration.properties file. The property value is the name of the header in the SSO request containing the respective user attribute for upserting the user:
SSO_PRIMARYKEY
SSO_SURNAME
SSO_GIVENNAME
SSO_EMAIL
SSO_STREET
SSO_CITY
SSO_STATE
SSO_POSTALCODE
SSO_COUNTRY
SSO_PHONE
SSO_MOBILE
SSO_PAGER
SSO_COMPANYNAME
SSO_PRIMARYKEY = SM_USER
This tells ExtraView which header field to look at to find the User ID.
SM_USER=GEORGE.FRANKENSTEIN
Note: Single Sign On is not the same as LDAP (Lightweight Directory Access Protocol) or the same as Active Directory (broadly speaking this is the Microsoft version of LDAP). SSO mechanisms may be used with or without LDAP or Active Directory, according to their capabilities.