Developing programmatic logins with the Java Authentication and Authorization Service

Use this topic to develop programmatic logins with the Java Authentication and Authorization Service.

Java Authentication and Authorization Service (JAAS) represents the strategic application programming interfaces (API) for authentication.

JAAS replaces the Common Object Request Broker Architecture (CORBA) programmatic login application programming interfaces (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 a custom JAAS login configuration, verify that the JAAS login configuration is properly defined. See Configuring programmatic logins for Java Authentication and Authorization Service 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.

  For details, see the following articles:

  • Adding the was.policy file to applications

  • Using PolicyTool to edit policy files

  • Configuring the was.policy file

  For more details on which APIs are protected by Java 2 security permissions, check the IBM Developer Kit, Java Technology Edition; JAAS and WebSphere Application Server public APIs documentation in Security: Resources for learning .

  Some of the APIs that are used in the sample code in this documentation and the Java 2 security permissions that are required by these APIs are in the following list:

  • javax.security.auth.login.LoginContext constructors are protected by the javax.security.auth.AuthPermission "createLoginContext" object.

  • javax.security.auth.Subject.doAs and com.ibm.websphere.security.auth.WSSubject.doAs methods are protected by the javax.security.auth.AuthPermission "doAs" object.

  • javax.security.auth.Subject.doAsPrivileged and com.ibm.websphere.security.auth.WSSubject.doAsPrivileged methods are protected by the javax.security.auth.AuthPermission "doAsPrivileged" object.

• Enhanced model to Java 2 Platform, Enterprise Edition (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 that is associated with the running thread inside a java.security.AccessController.doPrivileged code block. This oversight can present inconsistent behavior, which might have unwanted effects. The com.ibm.websphere.security.auth.WSSubject class provides a workaround to associate a Subject to a running thread. The com.ibm.websphere.security.auth.WSSubject class extends the JAAS model to Java 2 Platform, Enterprise Edition (J2EE) resources for authorization checks. If the Subject associates with the running thread 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 resource authorization checks.

• User interface support for defining new JAAS login configuration.

  You can configure a JAAS login configuration in the administrative console and store the JAAS login configuration in a configuration repository. Applications can define a new JAAS login configuration in the administrative console and the data is persisted in the configuration repository. However, WebSphere Application Server still supports the default JAAS login configuration format (plain text file) that is provided by the JAAS default implementation. If duplicate login configurations are defined in both the configuration repository and the plain text file format, the one in the repository takes precedence. Advantages to defining the login configuration in the configuration repository includes:

  • Administrative console support in defining JAAS login configuration

  • Central management of the JAAS login configuration

  • Distribution of the JAAS login configuration

• Application support for programmatic authentication.

  WebSphere Application Server provides JAAS login configurations for applications to perform programmatic authentication to the WebSphere security runtime. These configurations perform authentication to the WebSphere Application Server-configured authentication mechanism, Simple WebSphere Authentication Mechanism (SWAM), or Lightweight Third Party Authentication (LTPA) and user registry (Local OS, Lightweight Directory Access Protocol, or Custom) based on the authentication data that is supplied. The authenticated Subject from these JAAS login configurations contains the required principal and credentials that the WebSphere security runtime can use to perform authorization checks on J2EE role-based protected resources.

  Here are the JAAS login configurations that are provided by WebSphere Application Server:

  • WSLogin JAAS login configuration. A generic JAAS login configuration can use Java clients, client container applications, servlets, JavaServer Pages (JSP) files, and EJB components to perform authentication based on a user ID and password, or a token to the security runtime for WebSphere Application Server. However, this configuration does not honor the CallbackHandler handler that is specified in the client container deployment descriptor.

  • ClientContainer JAAS login configuration. This JAAS login configuration honors the CallbackHandler handler that is specified in the client container deployment descriptor. The login module of this login configuration uses the CallbackHandler handler in the client container deployment descriptor if one is specified, even if the application code specified one callback handler in the login context. This is for a client container application.

    A Subject authenticated with the previously mentioned JAAS login configurations contains a com.ibm.websphere.security.auth.WSPrincipal principal and a com.ibm.websphere.security.cred.WSCredential credential. If the authenticated Subject is passed in the com.ibm.websphere.security.auth.WSSubject.doAs or the other doAs methods, the product security runtime can perform authorization checks on J2EE resources based on the com.ibm.websphere.security.cred.WSCredential Subject.

• Customer-defined JAAS login configurations.

  You can define other
  JAAS login configurations to perform programmatic authentication to your authentication mechanism. See the Configuring programmatic logins for Java Authentication and Authorization Service for details. For the product security runtime 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:

Procedure

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.mycompany.com:2809");
         Context initialContext = new InitialContext(env);
         Object obj = initialContext.lookup("");
   
      // programmatic login code goes here.
   

   Complete this step prior to running 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 WebSphere Application Server within the cell to which you are authenticating. Pointing to one cell 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, Example: Getting the default initial context .

Example See the Example: Programmatic logins article.

Sub-topics

Related concepts

Related tasks

Related reference

Example: Getting an initial context by setting the provider URL property

Security: Resources for learning