An ALES Web Server SSM is used to secure web server resources hosted on IIS and Apache Web Server. For a description of features and capabilities see Web Server Security Service Module.
Deploying the Web Server SSM also requires deployment of Web Services SSM on the same machine. The Web Server SSM communicates with the ALES security framework through the Web Services SSM.
The IIS and Apache SSMs are bound to the web server as follows:
The Apache SSM is loaded as a module (mod_wles.so on UNIX or mod_wles.dll on Windows) on the server using the LoadModule and WLESConfigDir directives. For instructions, see Configuring the Environmental Binding for the Apache Web Server in the SSM Installation and Configuration Guide.
Single Sign-On
Web single sign-on enables users to log on to one web server and gain access to other web servers in the same domain without supplying login credentials again, even if the other web servers have different authentication schemes or requirements. For information and instructions, see Implementing Web Single Sign-On with ALES Identity Assertion.
The Web Server SSM has the following constraints and limitations:
Does not support cookie-based cross domain single sign-on except through SAML Browser/POST profile.
Does not support cookie-based cross domain forced logoff.
To support web farms, local configurations on each web server machine must be manually synchronized.
Requires use of transient, non-persistent cookies to maintain session state.
Does not support SAML Browser/Artifact profile.
Does not preserve the original POST data during redirection to an authentication form.
Does not save and transfer credentials between machines when more than one machine attempts to authenticate a user. Within a web farm, it is possible for a series of questions (on a form) to start on one machine and be transparently redirected to another machine within that web farm. The SSM does not save credentials that have already been entered in the same authentication attempt. Therefore, users are forced to re-enter credential information when more than one machine is involved.
Prerequisites
The instructions provided in this chapter assume the following:
Access to the ALES Administration Console on the Administration Server.
Installation of IIS or Apache web server.
Installation and configuration of the IIS SSM or Apache SSM and creation of the SSM instance on the web server machine.
Installation of the Web Services SSM on the web server machine.
Integration Tasks
The integration tasks described in this chapter are based on a scenario where the web server is secured by policies that determine who is able to log on. A template logon form is provided when the SSM instance is created. By following the provided instructions, you can deploy this form to the web server and test the policies.
The required security providers for securing web servers are:
Authentication
ASI Authorization
ASI Role Mapping
ALES Identity Assertion
ALES Credential Mapping
The following table provides information about each provider. For set-by-step instructions, see Configuring Security Providers in the Administration Console’s help system.
Table 2-1 Security Providers Used with Web Server SSMs
Provider
Setting
Authentication
See Authentication Providers in the console’s help system for information on configuring this provider. For using the ALES Identity Assertion Provider, see description below.
ASI Authorization
(Required) See Configuring an ASI Authorization Provider in the console’s help system for information on configuring this provider.
Any field that this provider and the ASI Role Mapping provider have in common must be set to the same value.
ASI Role Mapping
(Required) See Configuring an ASI Role Mapping Provider in the console’s help system for information on configuring this provider.
Any field that this provider and the ASI Role Mapping provider have in common must be set to the same value.
Log4 Auditor (Optional)
See Configuring a Log4j Audit Channel Provider in the console’s help system for information on configuring this provider.
ASI Adjudicator
See Configuring an ASI Adjudication Provider in the console’s help system for information on configuring this provider.
ALES Identity Assertion
See Configuring an ALES Identity Assertion Provider in the console’s help system for information on configuring this provider.
Important: This provider and the ALES Credential Mapping provider (see below) must have the same values in the following fields:
Trusted Keystore Trusted Keystore Type Trusted Cert Alias Trusted Cert Alias Confirm Trusted Cert Alias
ALES Credential Mapping
See Configuring a ALES Credential Mapping Provider in the console’s help system for information on configuring this provider.
Important: Some fields must have the same values set on the ALES Identity Assertion provider. See description above.
Define Web Server Resources in ALES
To secure web server resources, those resources must be defined in ALES. When defining web server resources in ALES, consider the following:
Resources are identified by canonical name. For example, for a web server with the names www.bea.com, www.beasys.com, www.web.internal.bea.com, and 204.236.43.12, the canonical name is www.bea.com.
The Web Server SSM provides HTTP headers, cookies, query arguments, and form values to the ALES security subsystem. It also decodes all URL-encoded context elements before presenting them to the security subsystem.
A resource is presented as the path element of a URL and the file or application name. For example, http://www.example.com/framework.jsp?FP=/products/aqualogic/ is presented as /framework.jsp. Query arguments/values (for example, FP=/products/aqualogic) are made available in the application context.
One way to secure a web site is to grant access based on a successful login to the site. This section describes how you would define the resources for securing a web server using the sample logon form provided when the IIS or Apache SSM is installed. These resources can be defined in ALES as shown in
Figure 2-1.
Figure 2-1 Resources Tree
To create these resources, perform the following steps:
In the Administration Console’s left pane, select the Resources node.
In the right pane, right-click policy at the top of the tree and select Add Resource.
On the Create Resource dialog, enter ssmws in the Name field and select binding from the Type dropdown field. Then click Ok.
The ssmws resource appears in the tree.
Right-click the ssmws resource and select Configure Resource. Then select the Distribution Point checkbox and click Ok.
Right-click the ssmws resource again and select Add Resource. Then enter favicon.ico in the Name field and click Ok.
Note:
The favicon.ico file is an icon requested by the Internet Explorer and Mozilla browsers for bookmarking URLs.
Right-click the ssmws resource and select Add Resource. Then enter test in the Name field and click Ok.
Right-click the test resource and select Add Resource. Then enter foo.html in the Name field and click Ok.
Right-click the foo.html resource and select Add Resource. Then enter NamePasswordForm.acc (for IIS) or NamePasswordForm.html (for Apache) in the Name field and click Ok.
Define Policies
When defining policies to secure a web server consider the following:
Since the SSM presents the full URL (including the protocol, server name, port, full path, and query string) to the ALES security framework, this information can be used in policy definitions.
Authorization policies must contain the privilege specifying the HTTP method being allowed. Default privileges provided by ALES include standard HTTP methods (GET, POST, PUT, etc.) Additional HTTP methods must be defined as Privileges before they can be used in policies.
Policies can return response attributes to the SSM for use by some logic on the web server.
The previous section described how to create resources for the sample logon form provided when the IIS or Apache SSM is installed. This section describes the Authorization and Role Mapping policies needed to secure these resources.
Authorization Policies
Table 2-2 lists Authorization policies to secure the web server using the NamePasswordForm form.
Table 2-2 Sample Web Server Application Resources Authorization Policies
Policy
Description
grant(GET, //app/policy/ssmws/favicon.ico, //role/Everyone) if true;
Allows unauthenticated users to access images used on the application login page.
grant(GET, POST, //app/policy/ssmws/test/NamePasswordForm.acc, //role/Everyone) if true;
Grants GET and POST privileges on the logon form for those in the Everyone role.
Note: Use NamePasswordForm.html for Apache.
grant(GET, //app/policy/ssmws/test/foo.html, //role/Admin) if true;
Grants GET privileges for those in the Admin role to access the foo.html page.
To create the authorization polices listed in Table 2-2, perform the following steps:
Expand the Policy node in the left pane and select Authorization Policies. Then click New at the bottom of the right pane.
On the Create Authorization Policy dialog, select the Grant radio button and do the following:
On the Privileges tab, select GET in the Select Privileges list and click <<Add.
On the Resources tab, expand ssmws. Then select favicon.ico and click <<Add.
On the Policy Subjects tab, select Everyone and click <<Add.
Repeat these steps to define the remaining two authorization policies. Notice that the Admin role is assigned to the foo.html resource.
Role Mapping Policies
This section describes how to modify two existing Role Mapping policies so that they apply to the web server resources created above.
Expand the Policy node in the left pane and select Role Mapping Policies. Then select the Admin role in the right pane and click Edit.
On the Role Mapping Policies page, select the Admin role for ASI and click Edit. This opens the Edit Role Mapping Policy dialog.
On the Resources tab, select ssmws in the Child Resources list and click <<Add.
Repeat these steps for the Everyone role.
Distribute the Policies
To distribute information to the SSM:
To make sure the providers are bound to the Web Server resources, expand the SSM configuration in the left pane and select the ASIAuthorizationProvider. Then open the Bindings tab, select //app/policy/ssmws from the dropdown field and click Bind.
Select Deployment in the left pane. Then use the Policy and Configuration tabs to distribute the policy and configuration information to the SSM.
Set Up and Test the Sample Application
Start the Web Services SSM.
When the Web Server SSM is started, it attempts to connect to the Web Services SSM.
Set up the ../wwwroot/test directory as shown in
Figure 2-2 and copy the following files to it:
NamePasswordForm.acc—(IIS only) located in BEA_HOME\ales30-ssm\iis-ssm\instance\<instance>\templates
NamePasswordForm.html—(Apache only) located in BEA_HOME\ales30-ssm\apache-ssm\instance\<instance>\wret\templates
NamePasswordForm.html—not provided, use your version of this file.
atnfailure.html—not provided, use your version of this file.
atzfailure.html—not provided, use your version of this file.
Figure 2-2 Deploying the Sample Application
Modify foo.html to redirect to the logon form.
For IIS, use: <FORM METHOD=POST ACTION="test/NamePasswordForm.acc">
For Apache, use: FORM METHOD=POST ACTION="/test/NamePasswordForm.html">
Start the web server, open a browser and go to foo.html.
For IIS: http://<machine_name_with_DNS_suffix>:80/test/foo.html.
For IIS: http://<hostmachine.cookiedomain>:8088/test/foo.html.
When the browser is redirected to the logon form, enter the System username/password (the defaults are system and weblogic) and click OK. You are granted access to foo.html.
Implementing Web Single Sign-On with ALES Identity Assertion
You can implement web single sign-on (SSO) for the following use cases:
Bi-directional SSO between Web Server SSMs
Any user that authenticates to one Web Server SSM can access any other Web Server SSM in the cookie domain without having to re-authenticate.
Uni-directional SSO between Web Server SSMs and WebLogic Server SSMs
Any user that authenticates to one Web Server SSM can access any other WebLogic Server SSM in the cookie domain without having to re-authenticate. However, a user that authenticates to a WebLogic Server SSM cannot access another WebLogic Server SSM or another Web Server SSM without re-authenticating.
SSO Between Web Servers
To implement SSO between Web Server SSMs:
Note:
For step-by-step instructions, see the Administration Console help file.
Using the Administration Console, configure the ALES Identity Assertion and ALES Credential Mapping providers for each participating Web Server SSM.
Configure the ALES Identity Assertion provider and the ALES Credential Mapping provider in each of the Web Server SSMs to use the same Trusted Cert Alias, Trusted Keystore, and Trusted Keystore Type.
Deploy these changes to the SSMs.
Web Server SSM to WebLogic Server SSM Single Sign-On
To implementing SSO between Web Server SSMs:
Note:
For step-by-step instructions, see the Administration Console help file.
Using the Administration Console, configure the ALES Identity Assertion and ALES Credential Mapping providers for each participating Web Server SSM and WebLogic Server SSM.
Note:
For each WLS SSM, make sure the ALES Identity Assertion provider does not use Base64 Decoding. This checkbox is located on the provider’s Details tab.
Configure all providers to use the same Trusted Cert Alias, Trusted Keystore, and Trusted Keystore Type.
