Edge Documentation

Overview

Single-Sign-On (SSO) and Sign-Off provides a convenient way for users to sign in once to enPortal and have enPortal manage sign-on credentials for proxied web applications. enPortal can then automatically sign-on on behalf of a user when they first access the proxied web content, and automatically sign-off once they log out of enPortal.

SSO Authentication Types

A number of different SSO token types are provided depending on what authentication mechanism a proxied application uses:

• HTTP Basic Authentication (basic): The most basic authentication mechanism, although still used it's not very common.
• NTLM Authentication (ntlm): This is also handled at the protocol layer and is not specific to a particular application. Typically this is implemented on Microsoft IIS servers. This authentication type supports NTLMv1, NTLMv2, and NTLM2 Session.
• Application (PIM) Specific: Many modern web applications manage user authentication and session handling themselves through either cookies or session tokens or some combination. In these cases enPortal PIMs provide custom authentication handlers to manage the sign-on and sign-off process. When creating tokens the list of available types will include the standard ones above, and any custom types provided by loaded PIMs.

SSO Assignment

SSO tokens can also be assigned at different levels:

• not assigned: when a user first accesses proxied content that requires authentication the user is prompted to enter access credentials. These are then saved against the specific user.
• User: Administrators can create tokens and assign to specific users.
• Domain: Administrators can create tokens and assign to a Domain, these tokens are then used for all users within the domain. If a user also has user-level tokens then those will take precedence over a domain-level token.
• Role: Administrators can create tokens and assign to a Role, these tokens are then used whenever a user is logged in using that role. If a user also has user-level tokens then those will take precedence over role-level tokens.

Stored & Pass-through Credentials

The credentials used can be:

• Stored Credentials: the actual username, password, and other credentials required are stored encrypted in the enPortal configuration database. When proxied content is accessed that requires authentication, the stored credentials are decrypted and used. For more information on the encryption used refer to the Product Security page.
• Pass-through Credentials: If the credentials used to access proxied content match the credentials used to log into enPortal, then enPortal can store these in-memory and use them when accessing proxied content that requires authentication. This avoids having to store credentials in the configuration database. To use pass-through credentials, use the following expressions instead of the actual username and password:
  • username: ${shim:session.credentials.username}
  • password: ${shim:session.credentials.password}

Managing SSO

Managing SSO tokens is done via the administration interface and either the Provisioning -> Domains & Users for user and domain-level tokens, or via Provisioning -> Roles & Content Assignment for role-level tokens.

In all three cases right-clicking on the user, domain, or role will allow the creation of new SSO tokens as shown in the screenshot below by selecting the New SSO option. Existing tokens will be visible in the Explorer tree and can be edited or deleted.

When creating new SSO tokens the first step is to pick the authentication type, as also shown in the screenshot below. The actual list of options will depend on the PIMs installed.

Managing User and Domain-level SSO tokens.

SSO Settings

When adding or editing an SSO token there are two main groups of settings:

1. The Auth Name, which defines the authentication type and is not editable. And the target application Host Name / IP and Port. These fields are used so enPortal can determine when to use this particular authentication token.
2. The authentication credentials. Typically this is username and password, but depending on the authentication type there may be different or additional fields. For example, in the screenshot below for NTLM authentication there is an optional domain field.

NTLM SSO token settings, notice additional Domain field.