Integrating ALES with Application Environments

Integrating ALES with Applications

This chapter provides information about ALES built-in support for integration with specific environments.

Overview

ALES provides a number built-in solutions for integration with the following environments:

Microsoft Internet Information Server
Apache HTTP Server
BEA WebLogic Server
BEA WebLogic Portal
AquaLogic Data Services Platform (ALDSP) 2.1 (formally Liquid Data).

Security Service Modules

Before a SSM can be integrated with a server, a SSM configuration that specifies the security providers must be created and the configuration must be bound to the SCM running on the same machine.

As shown in Figure 4-1, installation of ALES creates a default SCM configuration named adminconfig that contains a SSM configuration and security providers used by the Administration Server itself.

If the SSM instance will be located on the same machine, you can use the SCM and create a SSM configuration under it. If on a separate machine, you must create a new SCM. For step-by-step instructions on managing SCM and SSM configurations, see the Management Console help system.

Figure 4-1 Default SCM

Default SCM

To create a SSM configuration:

Open the Security Configuration folder.

Select Unbound Configurations in the navigation tree and click on Create a new Security Service Module Configuration in the right page.

On the General tab, complete the following fields and click Create.

Table 4-1 SSM Configuration ID

Field	Description
Configuration ID	This entry must match the SSM config ID that is specified when the SSM instance is created on the server machine. The configuration ID is the means by which the SSM receives it configuration from the SCM.
Description	(Optional) A brief description of the SSM.

SSM Security Providers

The security providers needed depend on the requirements of the application. This section describes the providers included with ALES 2.1. For specific uses of providers with the Web Server SSM, see Security Providers on page 4-9. For step-by-step instructions on managing providers, see the Management Console help system.

Table 4-2 Authentication Providers

Provider	Description
Weblogic Authenticator	Authenticate users with WebLogic's embedded LDAP directory.
ALES Identity Asserter	Supports web server authentication and single sign-on between web server SSMs. Use this provider in conjunction with the ALES Credential Mapper.
Database Authenticator	Authenticates users using the ALES relational database provider.
Single Pass Negotiate Identity Asserter	Supports identity assertion using HTTP authentication tokens from the SPNEGO protocol. For more information, see Enabling SPNEGO-based Single Sign-on.
SAML Identity Asserter	Accepts SAML assertions sent using the Browser POST Profile and returns the corresponding user. For more information, see Enabling SAML-based Single Sign-On.
Open LDAPAuthenticator	Authenticates users using an Open LDAP directory.
Active Directory Authenticator	Authenticates users using Active Directory.
NTAuthenticator	Authenticates users using Windows NT authentication.
iPlanet Authenticator	Authenticates users using an iPlanet LDAP directory.
Novell Authenticator	Authenticates users using a Novell LDAP directory.
X509 Identity Asserter	Supports identity assertion through an X.509 digital certificate, supporting ASN.1 encoding and decoding

Table 4-3 describes Authorization providers.

Table 4-3 Authorization Providers

Provider	Description
Weblogic Authorizer	Authorizes access to resources based on WebLogic security policy.
ASI Authorization Provider	Authorizes access to resources based on ALES security policy.

Table 4-4 describes Credential Mapping providers.

Table 4-4 Credential Mapping Providers

Provider	Description
Database Credential Mapper	Returns authentication credentials for a user (username and password) from a database.
SAML Credential Mapper	Returns a SAML assertion for an authenticated user. For more information, see Enabling SAML-based Single Sign-On.
ALES Identity Credential Mapper	Supports web server authentication and single sign-on between web server SSMs. Returns a ALES assertion for an authenticated user.
Weblogic Credential Mapper	Returns authentication credentials for a user (username and password) from the Weblogic LDAP directory.

Table 4-5 describes Role Mapping providers.

Table 4-5 Role Mapping Providers

Provider	Description
ASI Role Mapper	Returns a set or roles granted to a user on a protected resource based on ALES security policies.
Weblogic Role Mapper	Returns a set or roles granted to a user on a protected resource based on WebLogic security policies.

Web Server SSMs

This section covers Web Server SSMs in the following sections:

Web Server SSM Overview

An ALES Web Server SSM provides the environmental bindings between the ALES and a web server. It can provide six distinct services: Registry, Authentication, Authorization, Auditing, Role Mapping, and Credential Mapping.

Figure 4-2 Web Server SSM Components

Web Server SSM Components

A Web Server SSM makes access decisions for the web server to which it is bound. The security configuration on which the access control decisions are based is defined and deployed by the Administration Server via the Security Control Module.

A Web Server SSM can be tailored to specific needs. Using templates provided as part of the product, security developers can customize the look and feel of authentication pages and configure parameters that allow fine tuning for a particular installation. Web applications can have information added to the HTTP request by the security framework, such as roles and response attributes.

ALES provides three Web Server SSMs: IIS Web Server SSM (SSM), Apache Web Server SSM, and Web Services SSM (see Figure 4-3).

Figure 4-3 Web Server SSM Components

Web Server SSM Components

Web Server Environmental Binding

The environmental binding is used to bind to and interact with web servers. Binding a web server SSM to the server projects the ALES subsystem into the web server environment. The SSM accepts HTTPS requests from the web server and presents them to the ALES security framework.

Bindings are provided for two types of web servers: ASF Apache and Microsoft IIS. The second function is ultimately for enforcing access control and providing a means of implementing the SAML Browser/POST profile.

Additionally, the Web Server SSM implements the server-side includes (SSIs) that process SAML Browser/POST profile.

Web Services Security Service APIs

The Web Services Security Service APIs enable access to the ALES security framework. These APIs provide the following security services:

Note: The following topics provide a very brief description of these APIs. For more information, see Programming Security for Web Services.

Authentication Service

There are two variations of authentication, JAAS-based and identity assertion. JAAS-based authentication collects evidence (credentials) from a user in order to establish user identity.

Note: For more information on JAAS, see Java Authentication and Authorization Service (JAAS) on the Web at http://java.sun.com/products/jaas/.

Identity assertion authentication consumes a trusted token object to establish identity. The Web Services SSM supports both types of authentication.

JAAS authentication is highly variable and is dependent upon the configured authentication provider. An authentication provider can use several different types of questions (modeled as callbacks) to collect information from the user.

Note: The Web Services SSM does not support custom callback types.

Identity assertion authentication is linked to a specific protocol. For example, X.509 certificate assertion is only valid within the context of a 2-way SSL handshake, and SAML identity assertion is only valid in the context of an Oasis SAML profile. The Web Services SSM implements the Oasis SAML Browser/POST profile and consumes or produces a SAML Identity Assertion.

Authorization Service

In addition to providing a simple permit or denied decision on a URL, the authorization service also has the ability to return attributes into the request as determined by the access control policy implemented. Because the inclusion of coding in the application to handle these attributes creates an undue coupling between the application and security infrastructure, the SSM inserts these returned attributes into the HTTP request header. Depending upon the technology used (ASP, CGI, ISAPI), these headers can be extracted and used by the application.

Auditing Service

The auditing service audits all transactions through the security subsystem. Every URL accessed is sent through the auditing infrastructure.

Role Mapping Service

Although roles are primarily used in authorization, some applications may wish to have access to the roles to which a user is mapped for the purposes of role-based personalization. In order to provide this information to the running applications, the Web Services SSM adds a list of roles to the HTTP request header. Depending upon the technology used (ASP, CGI, ISAPI), the application can extract this list of roles from the header and use it.

Credential Service

The credential service returns sensitive credentials to an application so that the application can use systems that require a secondary (or tertiary) layer of authentication. The Web Services SSM extracts mapped credentials from the security system and makes them available in the HTTP header for use by the application. Depending upon the technology used (ASP, CGI, ISAPI), the application can extract the credential headers and use them to authenticate to other back-end systems.

Security Providers

Installing a SSM deploys a JAR file that contains all ALES security providers. However, before any of the security providers can be used, you must use the Administration Console to configure them. You have the option of configuring either the security providers that ship with the product or custom security providers, which you may develop yourself or purchase from third-party security vendors.

Note: To use security providers with the SSM, you must deploy the security provider MBean JAR file (MJF) to the providers directory on both the machine on which you install the SSM and on the machine on which you install the Administration Console.

The Web Server SSMs use the following security providers:

ALES Credential Mapping provider
ALES Identity Assertion provider
ASI Adjudication provider
ASI Authorization provider
ASI Role Mapping provider
Database Authentication provider
Log4j Auditing provider

For more information on security providers, see SSM Security Providers on page 4-3. For more information on how to develop custom security providers, see Developing Security Providers for BEA AquaLogic Enterprise Security.

Web Server SSM Features

This section describes the Web Server SSM features in the following sections

Web Single Sign-on Capabilities

This section covers the following topics:

What is Web 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. Figure 4-4 shows the basic components of a web single sign-on service.

Figure 4-4 Web Single Sign-on

Web Single Sign-on

While web single sign-on facilitates access and ease of use, it does not improve security. In fact, security requirements should be considered when implementing a web single sign-on solution.

Single Sign-On Use Cases

The Web Server SSM supports the following single sign-on (SSO) use cases.

Bi-directional SSO among Web Server SSMs—Once users are authenticated by a Web Server SSM, they are given a identity assertion token that they can use to access other Web Server SSM instances without being required to authenticate again (see Figure 4-5).

Figure 4-5 Web Server SSM to Web Server SSM Single Sing-on

Web Server SSM to Web Server SSM Single Sing-on

Uni-directional SSO from Web Server SSM to WebLogic Server 8.1 SSM instances—Once users are authenticated by a Web Server SSM, they are given an identity assertion token that they can use to access WebLogic Server 8.1 SSM instances without being required to authenticate again (see Figure 4-6).

Figure 4-6 Web Server SSM to WebLogic Server SSM Single Sign-On

Web Server SSM to WebLogic Server SSM Single Sign-On

Single Sign-On with ALES Identity Assertion

The Web Server and WebLogic Server 8.1 SSMs support single sign-on using the ALES Identity Assertion provider. For instructions on how to implement Single Sign-On, see "Configuring Web Single Sign-on with ALES Identity Assertion" in Installing the Web Server and Web Services Security Service Modules.

Authentication Service Features

The authentication service supports the following features:

Conversion of JAAS callbacks to asynchronous—Although the authentication service is JAAS based, the Web Server SSM masks the JAAS synchronous callback protocol from the web server. When form-based authentication is configured, the credentials are initially gathered and used for authentication. In most cases, an initial form gathers all credentials necessary for authentication.
All standard JAAS callbacks—Sun Microsystems defines seven types of callbacks: NameCallback, PasswordCallback, ChoiceCallback, ConfirmationCallback, LanguageCallback, TextInputCallback, TextOutputCallback.

Note: If a new callback type is encountered during authentication, the Web Server SSM ignores it.

Multiple authentication phases—JAAS may ask several series of questions using callbacks. Therefore, the SSM does not assume that answering one set of callbacks is sufficient.
Web farms—The following features are supported for web farms:

Redirect during credential gathering—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.
Single sign-on—Within a web farm it is possible that a user is authenticated on one machine and transparently redirected to another. However, a mechanism must be available by which the second machine can accept the identity from the first without having to re-authenticate the user. The identity is only shared within the same cookie domain.

Single sign-on with other SSMs—Can share identity with a custom application that is protected by the Java SSM or another client of the Web Server SSM. The Java SSM and the Web Server SSM use the ALES Credential Mapper and ALES Identity Assertion providers. Single sign-on is limited to a cookie domain.
SAML Browser/POST profile—Consumes an identity assertion from a SAML 1.1 Browser/POST transaction and provides an identity transfer service to serve SAML 1.1 identities to remote systems.
Custom, form-based authentication—Allows for the editing and customizing the forms used in form-based authentication.

Authorization Service Features

The authorization service supports the following features:

Resource form—De-references any use of ".." and decodes URL encoding. The resource is presented as the path element of a URL and the file or application name. For example, http://www.bea.com/framework.jsp?CNT=index.htm&FP=/products/aqualogic/ is presented as /framework.jsp. The query arguments CNT and FP and associated values are made available in the application context.
Allows for unprotected URLs—Always uses the isAuthenticationRequired() method to check if a resource is protected by a security system. This feature is important because you may want to leave some web server resources unprotected.
Checks for resource authorization—When checking for resource authorization, the following features are supported:

Includes rich web service request context—Because a web application cannot know what elements may be required for enforcement of security at the time of its authoring, it is important that information about the web services request be available in the context given to the security subsystem. The Web Server SSM provides HTTP headers, cookies, query arguments, and form values to the security subsystem. The SSM also decodes all URL encoded context elements before presenting them to the security subsystem.
Works with existing unmodified web applications—Does not require modification or special code to work with existing web applications running on the web server.

Retrieves response attributes during authorization—Retrieves response attributes during the authorization process and provides them in a form that a layered web application can use.

Auditing Service Features

The auditing service has the following capabilities:

Audits all transactions—All authentications, identity assertions, authorizations, role mappings, credential mappings and audit failures are automatically made available to the auditing infrastructure by the ALES security framework.
Audits session cleanup activity—The occurrence of idle and absolute timeouts are audited.

Role Mapping Features

The role mapping service supports hard-coded roles in applications. Generally hard-coding behavior into an application based on roles is not recommended. It is possible, however, that some customers may need to replace an existing system that uses this mechanism or may want to use roles for user interface personalization. Support for this feature requires that a list of mapped roles available from a security provider for a particular request be provided in a usable form by applications running within the web server.

Note: It is important to note that roles are not global in ALES but can change depending upon the resource and various elements of the context.

Credential Mapping Features

ALES defines two types of credential objects: username/password credentials and generic credentials; however, there is no limitation as to the format of objects that can be used. Credentials can be "mapped" and associated with a resource and identity or an alias.

The credential mapping service has the following features:

Provides mapped username/password credentials—Extracts mapped username/password credentials to the application running within the SSM. This username/password can be used for legacy SSO to log into a database or other system. The Web Server SSM does not use these credentials itself; it will make them available to the web server application.
Supports unknown credential types—Provides a way to inject other credential formats. Since these other formats are unknown to the SSM, they must be converted to a string before being presented to the application.

Administration Features

Administering the security configuration involves writing policies for users, groups, roles, and the web application resources that the SSM protects. The Web Server SSM has the following features:

Presents the full URL—The full URL (including the protocol, server name, port, full path, and query string) is presented to the ALES security framework as part of the context to allow its use in access control policy. Note that the resource presented to the system is in the canonical form. 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.
Uses the HTTP method as the action—The HTTP method (GET, POST, HEAD, PUT) is presented by the Web Server SSM as the action for authorization. In the administration system the privilege must match the action for a policy so this feature allows for separate security policies to be applied to POSTs, GETs, and other methods.
Passes in an application context—The application context is passed through to the SSM's authorization and role mapping security providers and is associated with any audit records logged. This context contains values relevant to the request environment at the time the security provider processes the call.

Session Management Features

To manage session behavior, the Web Server SSM supports the following capabilities:

Inactivity timeout—terminates a session after it has been inactive for a configurable period of time
Absolute timeout—terminates a session after a certain (usually large) period of time, thereby preventing a client from staying perpetually connected, which can be a security risk.
User logoff—allows for user initiated logoff.
Forced logoff—forces immediate logoff by terminating the session for a single DNS domain.
Session cookie—uses session cookie, not persistent cookies.

Configuration Features

The web server is configured to use the filter component of the Web Server SSM. Local configuration of the web server should only be necessary once and should be static. The Web Server SSM has the following configuration capabilities:

Logging channel—to support configuration and debugging.
Configurable flag to control logging and debug mode—to determine what messages are logged.

Web Server Constraints and Limitations

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.
Does not support special handling of third-party cookies.
Requires use of cookies to maintain session state.
The web server SSM must be manually configured into the web server.
Does not support load-balancing or failover in accessing the Web Services SSM.
Must be installed on the same machine as the web server to which it is bound.
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 is involved in an attempt 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.

Web Server SSM Integration Tasks

This section provides an overview of integration tasks. Integration tasks center on managing SSM configurations (including the security providers) and configuring the web server to use the web filters. For step-by-step instructions, see the Installing Web Server and Web Services Security Service Modules.

The major tasks performed are:

Create a SCM and a SSM configuration using the Administration Console. This includes specifying the security providers.

Create a parent resource for the application. This will contain ALES's representation of the application.

Create the SSM instance on the web server machine and enroll it in the ALES trust environment. The instance will use the security providers defined in step 1 above.

For detailed instructions on setting up Web Server SSM instances, see the Installing Web Server and Web Services Security Service Modules.
During the instance creation process, the default.properties configuration file is created. This file contains the connection information for the ALES services.

Configure the web server environmental binding as described in the next section. This loads the web filter on the server and establishes the connection between the web server and ALES.

Web Server Environmental Bindings

This section describes how the IIS and Apache SSMs bind to the web server.

Internet Information Server

To load the web server SSM into IIS:

Use the IIS management tool to call the ALES web server filter (wles_isapi.dll).

Set authentication to Anonymous and insure that Anonymous user has Read and Read/Execute permissions on the lib, ssl, and config directories where the SSM is installed.

Configure server's NamePasswordForm.acc file for:

<FORM METHOD=POST ACTION="/<directory>/NamePasswordForm.acc">
where <directory> is the location of the acc file.

Apache HTTP Server

To load the web server SSM into Apache HTTP server:

Add LoadModule, WLESConfigDir, ServerName, Alias, and Group directives to the server's httpd.conf file to load the SSM when the server is booted. The web filter file name is as follows:

mod_wles.dll (Windows) mod_wles.so (UNIX)

Modify the LD-LIBRARY_PATH statement in the envvars file (in ServerRoot/bin) to ensure that the server loads the dependency libraries for mod_wles.so.

Set the Apache ctl script to start or restart the server in the ServerRoot/bin directory.

Configure the NamePasswordForm.html file for the Apache Web Server as follows:

<FORM METHOD=POST ACTION="/test/NamePasswordForm.html">

WebLogic Server SSMs

This section provides an overview of integration tasks required for using the WebLogic Server SSM. For step by step instructions, see Installing WebLogic Server v8.1 Security Service Module. That guide provides specific steps for integration tasks associated with WebLogic Server, WebLogic Portal, and Aqualogic Data Services.

The WebLogic Server SSM basically provides a means of replacing WebLogic Server's security framework with ALES.

Warning: The WebLogic security framework controls access to it's own administration console as well as the applications it is hosting. When replacing this framework with ALES, you must configure ALES to secure the server's administration console when the WebLogic Server SSM is deployed. If this is not done, the WebLogic administration console will not be accessible.

WebLogic Server SSM Integration Tasks

Using the ALES Administration Console, create a SCM and a SSM configuration using, including the necessary security providers.

Create a parent Resource node that contains two branches: one for application resources and one for the WebLogic administration console. You can create the branch for the WebLogic administration console by copying the //asi/console tree using the Clone function.

Create the SSM instance on the web server machine and enroll it in the ALES trust environment. The instance will use the security providers defined in step 1 above.

For detailed instructions on setting up SSM instances, see the SSM installation guides.
During the instance creation process, the default.properties configuration file is created for the web server SSM. This file contains the connection information for the ALES services.

Modify the WebLogic domain's startup script as described in Installing WebLogic Server v8.1 Security Service Module.

WebLogic Server SSM Environmental Bindings

For instructions, see Installing the WebLogic Server v8.1 Security Service Module.