JAAS service configuration entry settings

 

To specify a list of JAAS login configurations for the application code to use...

Admin Console | Security | JAAS Configuration | Application Login Configuration

You can define additional login configurations for your applications. However, if the WAS LoginModule...

com.ibm.ws.security.common.auth.module.WSLoginModuleImpl

...is not used or the LoginModule does not produce a credential that is recognized by WAS, then the WAS security run time cannot use the authenticated subject from these login configurations for an authorization check for resource access.

You must invoke Java client programs that use JAAS for authentication with a JAAS configuration file specified. The WebSphere product supplies the default JAAS configuration file, wsjaas_client.conf under the $WAS_HOME/properties directory. This configuration file is set in...

$WAS_HOME/bin/launchClient.sh

...as...

JAAS_LOGIN_CONFIG=-Djava.security.auth.login.config=$WAS_HOME/properties/wsjaas_client.conf

If launchClient.sh file is not used to invoke Java client programs, make sure that the appropriate JAAS configuration file is passed to the JVM with the flag...

-Djava.security.auth.login.config

 

Configuration tab

ClientContainer Specifies the login configuration used by the client container application, which uses the CallbackHandler API defined in the client container deployment descriptor.

ClientContainer is the default login configuration for the WebSphere Application Server. Do not remove this default, as other applications that use it fail.

Default... ClientContainer

DefaultPrincipalMapping Specifies the login configuration used by Java 2 Connectors to map users to principals that are defined in the J2C Authentication Data Entries.

ClientContainer is the default login configuration for the WebSphere Application Server. Do not remove this default, as other applications that use it fail.

Default... ClientContainer

WSLogin Specifies whether all applications can use the WSLogin configuration to perform authentication for the WAS security run time.

This login configuration does not honor the CallbackHandler defined in the client container deployment descriptor. To use this functionality, use the ClientContainer login configuration.

The WSLogin configuration is the default login configuration for the WebSphere Application Server. Do not remove this default, as other applications that use it fail. This login configuration authenticates users for the WebSphere Application Server security run time. Use credentials from the authenticated subject returned from this login configurations as an authorization check for access to WAS resources.

Default... ClientContainer

 

Developing with the JAAS to log in programmatically

JAAS is a new feature in WAS v5. JAAS represents the strategic APIs for authentication and it replaces the CORBA programmatic login APIs. WebSphere Application Server provides some extension to JAAS:

  • Refer to the Developing applications that use CosNaming (CORBA Naming interface) article for details on how to set up the environment for thin client applications to access remote resources on a server.

  • If the application uses custom JAAS login configuration, verify that it is properly defined. See the Configuring JAAS login configuration article for details.

  • Some of the JAAS APIs are protected by Java 2 Security permissions. If these APIs are used by application code, verify that these permissions are added to the application was.policy file. See Adding the was.policy file to Application, Using the Policytool to edit policy file and Configure was.policy articles for details. For more details on which APIs are protected by Java 2 Security permissions, check the IBM Application Developer Kit, Java Technology Edition; JAAS and WAS public APIs javadoc in Resources for learning. Some of the APIs used in the sample code in this documentation and the Java 2 Security permissions required by these APIs follow...

  • Enhanced model to J2EE resources for authorization checks. Due to a design oversight in JAAS Version 1.0, the javax.security.auth.Subject.getSubject() method does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present an inconsistent behavior, which might have undesirable effects. The com.ibm.websphere.security.auth.WSSubject provides a workaround to associate a Subject to a thread of execution. The com.ibm.websphere.security.auth.WSSubject extends the JAAS model to J2EE resources for authorization checks. If the Subject associates with the thread of execution within the com.ibm.websphere.security.auth.WSSubject.doAs() method or if the com.ibm.websphere.security.auth.WSSubject.doAsPrivileged() code block contains product credentials, the Subject is used for J2EE resources authorization checks.

  • User Interface support for defining new JAAS login configuration. You can configure JAAS login configuration in the administrative console and store it in the WebSphere Common Configuration Model. Applications can define a new JAAS login configuration in the administrative console and the data is persisted in the configuration repository (stored in the WebSphere Common Configuration Model). However, WAS still supports the default JAAS login configuration format (plain text file) provided by the JAAS default implementation. If there are duplication login configurations defined in both the WebSphere Common Configuration and the plain text file format, the one in the WebSphere Common Configuration takes precedence. There are advantages to defining the login configuration in the WebSphere Common Configuration...

    • UI support in defining JAAS login configuration

    • JAAS configuration login configuration can be managed centrally

    • JAAS configuration login configuration is distributed in a Network Deployment installation

  • Application support for programmatic authentication. WebSphere Application Server provides JAAS login configurations for applications to perform programmatic authentication to the WebSphere security run time. These configurations perform authentication to the WebSphere-configured authentication mechanism (SWAM or Lightweight Third Party Authentication (LTPA)) and user registry (Local OS, Lightweight Directory Access Protocol (LDAP) or Custom) based on the authentication data supplied. The authenticated Subject from these JAAS login configurations contains the required Principal and Credentials that the WebSphere security run time can use to perform authorization checks on J2EE role-based protected resources. Here are the JAAS login configurations provided by the WebSphere Application Server...

  • Customer-defined JAAS login configurations. You can define other JAAS login configurations to perform programmatic authentication to your authentication mechanism. See the Managing Java Authentication and Authorization Service Login Configuration article for details. For the product security run time to perform authorization checks, the subjects from these customer-defined JAAS login configurations must contain the required principal and credentials.

  • Naming requirements for programmatic login on a pure Java client. When programmatic login occurs on a pure Java client and the property com.ibm.CORBA.validateBasicAuth equals true, it is necessary for the security code to know where the SecurityServer resides. Typically, the default InitialContext is sufficient when a java.naming.provider.url property is set as a system property or when the property is set in the jndi.properties file. In other cases it is not desirable to have the same java.naming.provider.url properties set in a system wide scope. In this case, there is a need to specify security specific bootstrap information in the sas.client.props file. The following steps present the order of precedence for determining how to find the SecurityServer in a pure Java client:

  1. Use the sas.client.props file and look for the following properties 

    com.ibm.CORBA.securityServerHost=myhost.mydomain
com.ibm.CORBA.securityServerPort=mybootstrap port
    If you specify these properties, you are guaranteed that security looks here for the SecurityServer. The host and port specified can represent any valid WebSphere host and bootstrap port. The SecurityServer resides on all server processes and therefore it is not important which host or port you choose. If specified, the security infrastructure within the client process look up the SecurityServer based on the information in the sas.client.props file.

  2. Place the following code in your client application to get a new InitialContext() 

    ...
   import java.util.Hashtable;
      import javax.naming.Context;
      import javax.naming.InitialContext;
      ...
   
// Perform an InitialContext and default lookup prior to logging 
// in so that target realm and bootstrap host/port can be 
// determined for SecurityServer lookup.
   
               Hashtable env = new Hashtable();
               env.put(Context.INITIAL_CONTEXT_FACTORY,             "
              com.ibm.websphere.naming.WsnInitialContextFactory");
               env.put(Context.PROVIDER_URL,             
              "corbaloc:iiop:myhost.companyname.com:2809");
               Context initialContext = new InitialContext(env);
               Object obj = initialContext.lookup("");

            // programmatic login code goes here.
    Complete this step prior to executing any programmatic login. It is in this code that you specify a URL provider for your naming context, but it must point to a valid WAS within the cell that you are authenticating to. This allows thread specific programmatic logins going to different cells to have a single system-wide SecurityServer location.

  3. Use the new default InitialContext() method relying on the naming precedence rules. These rules are defined in the article, Get the default initial context.