This chapter describes the various authentication options for an AquaLogic User Interaction deployment.
By default, AquaLogic User Interaction performs authentication using credentials stored in the AquaLogic Interaction Portal database. Beyond basic portal authentication, AquaLogic User Interaction can delegate authentication to other backend systems, such as:
Access control lists allow permissions to be granted to users and groups, and user and group properties can be pulled from backend services and mapped to portal users and groups. For details, see Access Control Lists and Profile Sources.
Authenticated users can have their credential information brokered to other backend services, allowing a single login to the portal to enable access to various systems. For details, see Brokering Credentials.
Delegating Authentication
The portal can be configured to delegate authentication to various other systems, including remote authentication tiers such as LDAP servers and Active Directory, SSO providers such as Oblix or Netegrity, and Windows Integrated Authentication (WIA). The following sections describe delegating authentication to these systems.
Delegating to a Remote Authentication Tier
Authentication can be delegated to a remote authentication tier by implementing an AquaLogic Interaction authentication service. The authentication service serves two roles: synchronization and authentication.
Synchronization against a backend authentication source imports users and groups into the AquaLogic Interaction portal database. This must be done before the portal user can authenticate against the backend authentication source. Passwords are not imported. This allows portal object permissions to be mapped to external users and groups, while maintaining authentication solely by the backend authentication source.
Authentication allows the portal to query a backend authentication source using a user’s credentials. The sequence of events in the process is as follows:
The user browses to the main portal page and is presented the login screen. User enters credentials.
AquaLogic Interaction sends a request to the backend authentication source using the configured AquaLogic Interaction authentication service.
The backend authentication source returns validity of user credentials.
If the user is authenticated, access to their profile in the portal is granted. If the user is not authenticated, they are presented with the login screen.
AquaLogic Interaction stores credentials in memory, and the user is identified by a browser cookie, if configured to do so. This allows the the user to be logged in automatically next time he visits the portal.
AquaLogic Interaction includes pre-made authentication services supporting LDAP and Active Directory backend systems. In addition, you can develop custom authentication services to authenticate against any backend system.
Additional resources
For details on configuring a pre-made authentication service, see Configuring an Authentication Sourcein the Administrator Guide for AquaLogic Integration.
For details on creating a custom authentication service, start with Authentication Services Internals in the AquaLogic User Interaction Development Documentation.
Delegating to an SSO Provider
Delegating authentication to an SSO provider can circumvent the AquaLogic Interaction login screen and present the user with the login method of the SSO provider. This allows authentication by non-Web form mechanisms, such as keycards or biometric authentication.
The sequence of events of this process as follows:
The user browses to the main portal page address.
The portal forwards this request to the SSO provider.
The SSO provider determines whether the user is already authenticated or needs to be authenticated. This might be done by checking the user’s browser cookies or by another method.
If the user is not authenticated, the SSO provider does what is necessary to gather credentials and authenticate the user.
The SSO provider returns the user to the portal and instructs AquaLogic Interaction to grant the user access to his profile.
For details on configuring the portal to use an SSO provider, see Configuring the Portal for SSO in the Administrator Guide for AquaLogic Interaction.
For details on configuring the portal and SSO, see Deploying Single Sign-Onin the Administrator Guide For AquaLogic Interaction.
Delegating to Windows Integrated Authentication
Delegating to Windows Integrated Authentication (WIA) is similar to delegating to an SSO source. With WIA, the user’s credentials are the same as their Windows network credentials. When the user browses to the portal page, the portal uses Windows to authenticate the user.
Prior to authenticating with WIA, user information must be crawled into the portal database using an Active Directory authentication source.
The sequence of events in the WIA authentication process is as follows:
The user logged into a Windows network browses to the main portal page.
The Portal returns a 401 Unauthorized message to the user browser.
The browser and portal perform the WIA handshake to validate the user.
The portal accepts the authentication and grants access to the user’s profile.
For WIA to work, the user must be logged into a Windows network and be using a browser, such as Internet Explorer, that supports the WIA handshake. WIA will fail over an HTTP proxy.
For details on configuring the portal to use WIA, see Configuring Integration with WIAin the Administrator Guide for AquaLogic Interaction.
For details on configuring the portal and SSO, see Deploying Single Sign-On in the Administrator Guide For AquaLogic Interaction.
Access Control Lists and Profile Sources
Access Control Lists(ACLs) allow users and groups to be granted permission to use and modify objects in the portal. Portal users who authenticate with any of the methods described in the section Delegating Authentication can be identified within the portal database and added to object ACLs.
A profile serviceuses an authentication service to pull user properties from backend systems such as LDAP services. Properties in the backend system are mapped to AquaLogic Interaction portal properties and synchronized with the authentication service.
For details on developing profile services, start with
Profile Service Internalsin the AquaLogic User Interaction Development Documentation.
Brokering Credentials
The credentials of a logged in user can be made available to other systems being accessed via the AquaLogic Interaction portal. This allows applications in the portal to display information from systems such as email or other enterprise applications without requiring for the user to log into each of these systems separately.
There are various ways AquaLogic Interaction can pass credentials to backend systems:
PassThrough: The credentials the user supplied at login can be sent to the remote tier as a Basic Authentication header. This is useful if both the portal login and the backend system login are based on the same authentication source, such as an LDAP service.
Preferences: Preferences can be created to hold the user’s credential, to be set individually by the end user. Preferences are stored encrypted in the portal database and controlled by the end-user.
UserInfo: User properties are mapped to credential information stored in an LDAP service or other backend source. Credentials are automatically populated for each user.
SSO: An SSO token can be forwarded to the remote tier. This only works if the remote tier application can accept an SSO token. In cases where an SSO token is not accepted, some SSO Providers provide an API to convert the SSO token to name and password. This is dependent on the SSO vendor and the configuration of the SSO provider.
Lockbox: User credentials can be stored in a lockbox in the AquaLogic Interaction credential vault. The credential vault provides a central repository that securely stores and manages credentials. Portlets that need credentials to access backend systems can securely retrieve appropriate user credentials.
For details on developing portlets that use brokered credentials, start with Introduction: Portlet Securityin the AquaLogic User Interaction Development Documentation.
