Enportal/5.5/admin/user administration/sso: Difference between revisions
imported>Jason.nicholls No edit summary |
imported>Jason.nicholls |
||
Line 26: | Line 26: | ||
The credentials used can be: | 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. | * 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.5/admin/system_administration/security|Security Overview]] documentation. | ||
* 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. | * 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. |
Revision as of 07:45, 24 October 2014
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 Security Overview documentation.
- 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.