Content provider policy single sign-on
When creating a policy for the profile, define the authentication to configure single sign-on between the web application bridge and the secured web application.
HTTP Basic
HTTP basic authentication provides simple access control to web resources. No cookies, session identifiers, or login pages are necessary. Therefore, this option is not secure unless it is used with an external secure system such as SSL.
Select an existing credential vault slot ID to specify where to pick the authentication credentials.
Create the credential vault slot before configuring the policy authentication.
HTTP Digest
HTTP digest authentication provides simple, encrypted access control to web resources.
Select an existing credential vault slot ID to specify where to pick the authentication credentials.
Create the credential vault slot before configuring the policy authentication.
Form-based authentication
Some sites require us to log in with a form before we are allowed to browse the site. Set up the web application bridge to emulate these steps. This feature is called form-based authentication. The web application bridge supports one type of form-based authentication.
The supported technique assumes the authentication server sends back one or more cookies in response to a successful authentication attempt. These cookies are then used on all subsequent calls within that Web Dock portlet. That is, it is assumed the login (or challenge) location and the actual URL are separate entities. The first location is used only to authenticate and returns a cookie in a standard HTTP 1.1 2XX response message. The second and all subsequent locations use the cookies from the first response.
Gather the following information before configuring form-based authentication:
- The URL that is the target of the login submission form
- The input parameters used for the user ID and password
- Any hidden input fields on the form that might be used during the authentication process.
To locate the target URL of the form submission, look for the <FORM> tag on the login page. Browse the source of the page. Then, locate the ACTION attribute. The URL in the ACTION attribute is the URL that specify. Enter this URL as the Login URL value. The Login method field specifies the HTTP method (for example: POST, GET). The HTTP method is used to make the authentication request to the Login URL. Its value is the Method attribute of the <FORM> tag.
Next, find the <INPUT> fields for the user ID and password. The values for the NAME attributes are used for the User name parameter and Password parameter values.
Locate any <INPUT TYPE="hidden" ...> elements on the source page. They provide name-value pairs to the system for login and might be important for the process. The web application bridge must also send them. Enter the hidden values in Login parameter. Enter these values as a series of comma-separated name-value pairs.
Authenticate with the server one time. Directly access the site and observe the response in a debugger tool. Check the cookies returned as part of the authentication request sent to the Login URL. Cookies returned as part of "Set-Cookie" response headers are session cookies. Specify the session cookies as a comma-separated list.
Select an existing credential vault slot ID to specify where to pick the authentication credentials.
Create the credential vault slot before configuring the policy authentication.
When a user provides the wrong credentials in personalize mode, the user sees the contents because of the session associated with the portal in form authentication. The user must log out and clear all the caches. Then, they must log in again. If the user goes back to the form authentication page, the user sees the page cannot be displayed. The user must return to personalize mode and enter the correct credentials for the application. When they click submit, they can view all the contents in view mode of Web Dock portlet.
SPNEGO authentication
Use the Simple and Protected GSS-API Negotiation (SPNEGO) as the web authenticator for the application server. SPNEGO support relies on the scenario where IBM WebSphere Application Server is already configured for SPNEGO trust association interceptor (SPNEGO TAI) web authentication.
The following prerequisites are required for this scenario:
- You installed IBM WebSphere Portal on a Windows operating system.
- We are using Microsoft Active Directory as the LDAP user registry.
- SPNEGO TAI is already enabled on WebSphere Application Server.
Support SPNEGO as an authentication mechanism in the web application bridge:
- To set up delegation:
- Open the Active Directory server user properties window.
- Go to the Delegation tab for the Active Directory server user ID the application uses.
- Select Trust this user for delegation to any service (Kerberos only).
Do not set this option for individual client users. Instead, set this option only for the application server ID.
- Click OK.
Windows Server 2000 systems: Delegation capability is set in the account options list of the account tab. Check the Account is trusted for delegation check box.
- Enter the user ID and password on the client workstation to log in to the local or trusted remote Windows domain.
- Access WebSphere Portal through a browser either on the local Windows domain or on a trusted remote Windows domain.
- To configure the Firefox browser for SPNEGO:
- Type about:config in the address bar.
- Type auth in the Filter field.
- Set the following two items to the SSO domain:
- network.negotiate-auth.delegation-uris
- network.negotiate-auth.trusted-uris
- To configure the Internet Explorer browser for SPNEGO:
- Go to Tools > Internet options.
- Select the Security tab.
- Select Local intranet.
- Click Sites.
- Add the SSO domain.
- Select the Advanced tab.
- Verify the Enable Integrated Windows Authentication check box is checked.
- Click OK.
- Restart Internet Explorer for the changes to take effect.
Parent Web application bridge