15.7 Mapping Identities at Connector Boundaries

 <  Day Day Up  >  

The Java Connector Architecture allows for applications to access resources ”typically, non-J2EE applications ”in an architected fashion. For every resource that is accessed, a resource adapter is expected to be registered with the J2EE container. Applications obtain connections to these resources by using the appropriate resource adapter.

Back-end systems are likely to have their own security mechanisms to secure access to those resources. In many cases, these adapters expect some form of credential to be made available when creating a connection. Typically, the credential is in the form of a user ID and password pair. Therefore, a user ID and password pair are made available to the resource adapter when a connection is created. The JCA framework provides two ways to make the credential available to the resource adapters.

  1. In an application-managed authentication, the application will explicitly pass a user ID and password when it requests connections.

  2. In a container-managed authentication, the container will make a user ID and password pair available to the resource adapter.

In the context of this discussion, the container-managed authentication is of particular interest.

A J2EE application is allowed to create connections to any non-J2EE application using JCA. For example, an application can connect to a database by using a JDBC resource adapter. In such cases, the user ID and password pair that are made available to the connection are based on many factors, including the resource adapter type ”in this example, JDBC ”and target instance ”for example, DB2 database AccountDB hosted on machine with hostname accounts.accountinc.com .

Consider a user, Bob, accessing a J2EE application that in turn accesses a database. One end of the spectrum is where all the users in the J2EE container environment are mapped to a single identity when accessing the resource adapter ”for example, the identity db2admin . This is the case of a many-to-one mapping per resource adapter. On the other end of the spectrum is where the user's identity is effectively propagated to the third tier . This gives rise to a one-to-one mapping of identities at the JCA boundary. For example, the identity bob on J2EE container hosted in ibm.com is mapped to the identity bobsmith in the database domain. Of course, there can be other possible mappings in this spectrum. For example, all managers have a manager_user identity when accessing the database, whereas others have a restricted_user identity.

In order for the J2EE container to accommodate the wide spectrum of the mapping that is required and to allow for a flexible and extensible architecture, the container must allow for an identity/credential mapping facility at the JCA boundary. An example of this is illustrated in Figure 15.7.

Figure 15.7. Mapping Identities in JCA

graphics/15fig07.gif

As shown in Figure 15.7, the currently executing identity, which may in turn be based on the delegation policies associated with a J2EE component, will be considered along with the target resource adapter characteristics. The mapping layer is expected to use this information to make a decision as to which identity is to be used when accessing back-end applications. The back-end applications in Figure 15.7 are a database, an IBM Customer Information Control System, and an enterprise resource planning application. In some cases, the client's credential may be propagated to the back-end application without any change. For example, if the back-end application accepts a Kerberos credential, a Kerberos ticket associated with the user accessing the J2EE application may be propagated to the resource adapter, thus giving rise to a one-to-one mapping effectively.

In order to accommodate such varied scenarios flexibly, the implementation of the mapping layer can be effectively achieved as a JAAS LoginModule . A container can use a LoginModule so that it can map the identity, represented as a JAAS Subject under which the business logic is performed, to a different identity, resulting in a JAAS Subject , based on the target system being connected to.

 <  Day Day Up  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net