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.
User Attributes
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
Example
- In the ExtraView Configuration.Properties file you have or will insert an entry – SSO_PRIMARYKEY = SM_USER This tells ExtraView which header field to look at to find the User ID.
- The behavior setting named SSO_STATE is set to a value of YES within ExtraView
- The request header generated by the SSO software has a field: SM_USER=GEORGE.FRANKENSTEIN
- When the SSO software calls the ExtraView application, with the request header in step 3, it will have authenticated that GEORGE.FRANKENSTEINis a valid user for ExtraView
- ExtraView will see that the request from the SSO software contains the header SM_USER = GEORGE.FRANKENSTEIN
- The user GEORGE.FRANKENSTEIN is then signed on automatically, and no sign on screen is generated. Typically the user lands directly on the ExtraView Home Page.
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.