1. Programmer's Guide
  2. Use the Service Locator to Create HDR Sessions
  3. Authorization Considerations

Authorization Considerations

This section describes the different behaviors of the ServiceLocator.login method in local and remote mode, and the effect of the Java Authentication and Authorization Service (JAAS) on HDR authentication.

ServiceLocator.login

The behavior of ServiceLocator.login depends on whether or not the calling code is protected by the application server:

  • If ServiceLocator.login is called from code running outside of a container, the identity and credentials passed to login are presented as the user name and password for the user when authenticating.
  • If ServiceLocator.login is called from code running outside of a container, the identity and credentials passed to login are presented as the user name and password for the user when authenticating.
  • If ServiceLocator.login is called from code running inside of a container (always the case in local mode), the behavior depends upon whether or not the application server has been configured to manage access to the component. If the component is protected by the container, the user name and password values are ignored; the ServiceLocator uses the user name and password of the current EJB session context (javax.ejb.SessionContext), which is established by the application server before it permits access to the component. The behavior for unprotected components is more complicated and is described below.

Note:

ServiceLocator.login ignores the user name and password passed to it when executing within a protected component within an application server, and uses the user name associated with the current EJB SessionContext. That user has to be authorized to access HDR functionality by both JAAS and the HDR Security Service. Session initiation otherwise fails and a Session could not be created authorization exception is thrown.

When calling ServiceLocator.login from code running inside of a container, the ServiceLocator.login call only succeeds if made from within a component whose EJB SessionContext includes details of an authenticated user. Users are associated with an EJB SessionContext when they first attempt access to a protected component. The deployment configuration of your application and WebLogic determine which components are protected. If a component is protected, the application server authenticates any user before permitting access to the component. For web applications, this is typically achieved through a login screen.

Once authenticated, the user identity can be propagated between components. This essentially means that a call to ServiceLocator.login may fail if it is called from an unprotected component and no authentication has occurred. You should thus ensure that you protect the entry points to your applications with an appropriate security constraint in your WebLogic deployment descriptors.

Example 4-3 Use ServiceLocator by Calling Login From a Remote Client

This code sample uses ServiceLocator by calling Login from an RMI Client outside of an WebLogic: 

Properties properties = new Properties();
properties.setProperty(ServiceLocator.CLIENT_MODE, ServiceLocator.REMOTE);
ServiceLocator serviceLocator = ServiceLocator.getInstance(properties);
serviceLocator.login("userName", "password");
RimService rimService = serviceLocator.getRimService();
IMPService impService = serviceLocator.getIMPService();