Enportal/5.6/admin/user administration/sso - Revision history

imported>Mike.berman: 1 revision: update SSO page to add note

2016-03-17T21:28:57Z

1 revision: update SSO page to add note

← Older revision	Revision as of 21:28, 17 March 2016
(No difference)

imported>Mike.berman: /* SSO Settings */

2016-03-17T21:16:42Z

SSO Settings

← Older revision		Revision as of 21:16, 17 March 2016
Line 52:		Line 52:

	[[File:enportal-5.5-sso-ntlm.png\|frame\|center\|NTLM SSO token settings, notice additional Domain field.]]		[[File:enportal-5.5-sso-ntlm.png\|frame\|center\|NTLM SSO token settings, notice additional Domain field.]]


			{{Note\|There are five special characters that are not supported in PIM credentials, which are <tt>'</tt> , <tt>"</tt> , <tt>)</tt> , <tt>}</tt> , and <tt>\</tt> . This should be taken into consideration when entering PIM credentials or setting up SSO.}}

imported>Jason.nicholls: /* SSO Authentication Types */

2015-05-21T15:07:34Z

SSO Authentication Types

← Older revision		Revision as of 15:07, 21 May 2015
Line 13:		Line 13:
	* HTTP Basic Authentication (basic): The most basic authentication mechanism, although still used it's not very common.		* 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.		* 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.
	* Kerberos (kerberos): Provides Kerberos authentication by the Microsoft HTTP ''Negotiate'' authentication extension. Please note this authentication method requires additional configuration and network access to both the proxied web application and Kerberos server. Refer to the Kerberos ~~configuration~~ page for more information.		* Kerberos (kerberos): Provides Kerberos authentication by the Microsoft HTTP ''Negotiate'' authentication extension. Please note this authentication method requires additional configuration and network access to both the proxied web application and Kerberos server. Refer to the [[enportal/5.6/admin/user_administration/sso/kerberos\|Kerberos Configuration]] page for more information.
	* ''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.		* ''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.

imported>Jason.nicholls: /* SSO Authentication Types */

2015-05-21T15:06:18Z

SSO Authentication Types

← Older revision		Revision as of 15:06, 21 May 2015
Line 13:		Line 13:
	* HTTP Basic Authentication (basic): The most basic authentication mechanism, although still used it's not very common.		* 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.		* 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.
			* Kerberos (kerberos): Provides Kerberos authentication by the Microsoft HTTP ''Negotiate'' authentication extension. Please note this authentication method requires additional configuration and network access to both the proxied web application and Kerberos server. Refer to the Kerberos configuration page for more information.
	* ''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.		* ''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.

imported>Jason.nicholls: 1 revision

2015-04-30T11:18:26Z

1 revision

← Older revision	Revision as of 11:18, 30 April 2015
(No difference)

imported>Jason.nicholls: /* Overview */

2014-10-27T07:44:07Z

Overview

New page

[[Category:enPortal 5.6]]
{{DISPLAYTITLE:Managing Single-Sign-On (SSO)}}
==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.

[[File:enportal-5.5-sso-diagram.png|thumb|500px|center|enPortal manages signing on to proxied applications on behalf of the user.]]

=== 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, and no existing token is applicable, 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. These tokens are the most specific and take precedence over Role or Domain-level tokens.
* Role: Administrators can create tokens and assign to a Role, these tokens are then used whenever a user is logged in using that role. Role-level tokens take precedence over Domain-level tokens.
* Domain: Administrators can create tokens and assign to a Domain, these tokens are then used for all users within the domain.

=== 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 [[enportal/5.6/admin/system_administration/security|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: <tt>${shim:session.credentials.username}</tt>
** password: <tt>${shim:session.credentials.password}</tt>

== 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.

[[File:enportal-5.5-sso.png|frame|center|Managing User and Domain-level SSO tokens.]]

=== SSO Settings ===

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

# 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.
# 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.

[[File:enportal-5.5-sso-ntlm.png|frame|center|NTLM SSO token settings, notice additional Domain field.]]