11 Using JASPIC for a Web Application

WebLogic Server supports the use of Java Authentication Service Provider Interface for Containers (JASPIC) to configure an Authentication Configuration Provider for a Web application and using that instead of the default WLS authentication mechanism for that Web application. Learn how to configure JASPIC for the deployed web application.

This section assumes that you are familiar with a basic overview of JASPIC, as described in JASPIC Security in Understanding Security for Oracle WebLogic Server.

Overview of Java Authentication Service Provider Interface for Containers (JASPIC)

The JASPIC Authentication Configuration provider assumes responsibility for authenticating the user credentials for a Web application and returning a subject. It authenticates incoming Web application messages and returns the identity (the expected subject) established as a result of the message authentication to WebLogic Server.

The JASPIC programming model is described in the Java Authentication Service Provider Interface for Containers (JASPIC) specification (http://www.jcp.org/en/jsr/detail?id=196). It defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms can be integrated in server Web application message processing containers or runtimes.

WebLogic Server allows you to use JASPIC to delegate authentication for Web applications to your configured Authentication Configuration providers. You do not have to modify your Web application code to use JASPIC. Instead, you use the WebLogic Server Administration Console or WLST to enable JASPIC for the Web application post deployment.

For each of your deployed Web applications in the domain, determine whether you want JASPIC to be disabled (the default), or select one of your configured Authentication Configuration providers to authenticate the user credentials and return a valid subject. If you configure an Authentication Configuration provider for a Web application, it is used instead of the WLS authentication mechanism for that Web application. You should therefore exercise care when you specify an Authentication Configuration provider to make sure that it satisfies your security authentication needs.

Do You Need to Implement an Authentication Configuration Provider?

If you have a specific requirement that is not addressed by the default WebLogic Authentication provider, then you can implement your own Authentication Configuration provider.

You can use either the default WebLogic Server Authentication Configuration provider, or you can implement your own. To use the default WebLogic Server Authentication Configuration provider and configure it, see the steps described in Securing JASPIC Security.

As described in the Java Authentication Service Provider Interface for Containers (JASPIC) specification (http://www.jcp.org/en/jsr/detail?id=196), the Authentication Configuration provider (called "authentication context configuration provider" in the specification) is an implementation of the javax.security.auth.message.config.AuthConfigProvider interface.

The Authentication Configuration provider provides a configuration mechanism used to define the registered Server Authentication Modules (SAM's) and bindings to applications that require protection from unauthenticated/authorized access.

Do You Need to Implement a Principal Validation Provider?

Authentication providers rely on Principal Validation providers to sign and verify the authenticity of principals (users and groups) contained within a subject. The Principal Validation provider, thus, prevents malicious individuals from tampering with the principals stored in a subject.

Principals are sent to the specified Principal Validation provider, which signs the principals and then returns them to the client application via WebLogic Server. Whenever the principals stored within the subject are required for other security operations, the same Principal Validation provider will verify that the principals stored within the subject have not been modified since they were signed.

Such verification provides an additional level of trust and may reduce the likelihood of malicious principal tampering. The authenticity of the subject's principals is also verified when making authorization decisions.

You must therefore use a Principal Validation provider as described in Principal Validation Providers.

Whether you use the existing WebLogic Principal Validation provider or implement a custom Principal Validation provider depends on the type of principals you are using:

  • WebLogic Server principals — The WebLogic Principal Validation provider includes implementations of the WLSUser and WLSGroup interfaces, named WLSUserImpl and WLSGroupImpl. These are located in the weblogic.security.principal package.

    It also includes an implementation of the PrincipalValidator SSPI called PrincipalValidatorImpl (located in the com.bea.common.security.provider package). To use this class, make the PrincipalValidatorImpl class the runtime class for your Principal Validation provider. See the PrincipalValidator SSPI for usage information.

  • Custom Principals — If you have your own validation scheme and do not want to use the WebLogic Principal Validation provider, or if you want to provide validation for principals other than WebLogic Server principals, then you need to develop a custom Principal Validation provider.

    Note:

    If you add custom principals, you must add a Principal Validation provider or authorization fails. The WebLogic Server security framework performs principal validation as part of authorization. (The only exception is if you are using JACC for authorization. Even in the case of JACC, if your Web application or EJB accesses any other server resource (for example, JDBC), WebLogic Server authorization and principal validation are used.)

    In this case, you must also develop an Authentication provider. The AuthenticationProviderV2 SSPI includes a method called getPrincipalValidator in which you specify the Principal Validation provider's runtime class. WebLogic Server uses this method to get the Principal Validation provider. (In this use, the other methods can return null. )

Both options are described in Principal Validation Providers in Developing Security Providers for Oracle WebLogic Server.

Implement a SAM

A key step in adding an authentication mechanism to a compatible server-side message processing runtime is acquiring a Server Authentication Module (SAM) that implements the desired authentication mechanism.

You must implement your own SAM that works with the default WebLogic Server Authentication Configuration provider, or with your own Authentication Configuration provider.

The SAM represents the implementation of a server-side authentication provider that is JASPIC-compliant. As described in the Java Authentication Service Provider Interface for Containers (JASPIC) specification (http://www.jcp.org/en/jsr/detail?id=196), a SAM implements the javax.security.auth.message.module.ServerAuthModule interface and is invoked by WebLogic Server at predetermined points in the message processing model.

Note:

A sample SAM implementation is described in Adding Authentication Mechanisms to the GlassFish Servlet Container. Although written from the GlassFish Server perspective, the tips for writing a SAM, and the sample SAM itself, are instructive.

Configure JASPIC for the Deployed Web Application

To configure JASPIC for your deployed Web application, you must add the jar for your SAM to the system classpath using the command line, enable JASPIC in your domain using the WebLogic Server Administration Console, and configure the desired Authentication Configuration provider to specify the classname of the SAM.

Perform the following steps to configure JASPIC for a Web application:

  1. Add the jar for your SAM to the system classpath via the startup scripts or the command line used to start the WebLogic Server instance.

    If you also configured a custom Authentication Configuration provider, you must add the jar for your custom Authentication Configuration provider to the system classpath via the startup scripts or the command line used to start the WebLogic Server instance.

  2. Enable JASPIC in the domain, as described in Configuring JASPIC Security.

  3. Configure the WebLogic Server Authentication Configuration provider or the custom Authentication Configuration provider to specify the classname of the SAM as described in Configuring JASPIC Security.

  4. In the left pane of the Console, select Deployments.

    A table that lists the deployments currently installed on WebLogic Server appears in the right pane. The Type column specifies whether a deployment is an Enterprise application, a Web application, or an EJB module.

  5. In the right pane, click the name of the Web application you want to configure.

  6. Select Security > JASPIC to view and change the JASPIC properties.

    By default, JASPIC is disabled for Web applications. To enable JASPIC for this Web application, select the correct Authentication Configuration providers from the drop-down list.

  7. Click Save to save any changes.

  8. Save the changes to the deployment plan, as prompted.

  9. Repeat steps 5 through 7 for any additional Web applications for which you want to enable JASPIC.

  10. Redeploy the Web application.

  11. Restart WebLogic Server.