Use this topic to develop programmatic logins with the Java Authentication and Authorization Service.
JAAS replaces the Common Object Request Broker Architecture (CORBA) programmatic login application programming interfaces (APIs).
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.
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 (LDAP), custom registries, or federated repositories) 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.
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.
You can define other JAAS login configurations to perform programmatic login which creates a custom Subject in either the client or server process. Certain credentials and principals are required in the Subject for the product security runtime to use it for sending authentication information from the client over a protocol or to use it for handling authorization on the server. The required credentials are generated from provided login modules.
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:
LoginContext lc = null; Subject subject = null; try { lc = new LoginContext("WSLogin", new WSCallbackHandlerImpl("userName", "password")); } catch (LoginException le) { System.out.println("Cannot create LoginContext. " + le.getMessage()); // Insert the error processing code } catch(SecurityException se) { // Insert the error processing code } try { lc.login(); subject = lc.getSubject(); // setting the subject on the thread to use for outbound requests. // Note: This overrides the existing subject which you might want to save first. com.ibm.websphere.security.auth.WSSubject.setRunAsSubject(subject); } catch(LoginException le) { System.out.println("Fails to create Subject. " + le.getMessage()); // Insert the error processing code }
As shown in the example, the new login context is initialized with the WSLogin login configuration and the WSCallbackHandlerImpl callback handler. Use the WSCallbackHandlerImpl instance on a server-side application where you do not want prompting. A WSCallbackHandlerImpl instance is initialized by the specified user ID, password, and realm information. The present WSLoginModuleImpl class implementation that is specified by the WSLogin login configuration can only retrieve authentication information from the specified callback handler. You can construct a login context with a Subject object, but the Subject is disregarded by the present WSLoginModuleImpl implementation. For product client-container applications, replace WSLogin login configuration by ClientContainer login configuration, which specifies the WSClientLoginModuleImpl implementation that is tailored for client container requirements.
For a pure Java application client, the product provides two other callback handler implementations: WSStdinCallbackHandlerImpl and WSGUICallbackHandlerImpl, which prompt for user ID, password, and realm information on the command line and pop-up panel, respectively. You can choose either of these product callback handler implementations, depending on the particular application environment. You can develop a new callback handler if neither of these implementations fit your particular application requirement.
You also can develop your own login module if the default WSLoginModuleImpl implementation fails to meet all your requirements. This product provides utility functions that the custom login module can use, which are described in the next section.
In cases where no java.naming.provider.url property is set as a system property or in the jndi.properties file, a default InitialContext context does not function if the product server is not at the localhost:2809 location. In this situation, construct a new InitialContext context programmatically ahead of the JAAS login. JAAS needs to know where the security server resides to verify that the entered user ID or password is correct, prior to performing a commit method. By constructing a new InitialContext context in the way specified below, the security code has the information that is needed to find the security server location and the target realm.
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(""); LoginContext lc = null; try { lc = new LoginContext("WSLogin", new WSCallbackHandlerImpl("userName", "realm", "password")); } catch (LoginException le) { System.out.println("Cannot create LoginContext. " + le.getMessage()); // insert error processing code } catch(SecurityException se) { System.out.printlin("Cannot create LoginContext." + se.getMessage(); // Insert error processing } try { lc.login(); } catch(LoginException le) { System.out.printlin("Fails to create Subject. " + le.getMessage()); // Insert error processing code }
In this information ...Subtopics
Related concepts
Related tasks
| IBM Redbooks, demos, education, and more(Index) |