Overview | Package | Class | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## Package com.fujitsu.iflow.ddframework.intf

The Framework Adapter (DdFramework) Interface handles user authentication and manages directory and document service objects.

See:
Description

Interface Summary
DdFramework | The DdFramework interface handles user authentication and manages the directory and documentary services objects for those users.

## Package com.fujitsu.iflow.ddframework.intf Description

The Framework Adapter (DdFramework) Interface handles user authentication and manages directory and document service objects. The Framework Adapter authenticates and manages the Directory Service (DIR) and the Document Management System adapters.

Authentication: When an Interstage BPM user attempts to log into the Server, the Server invokes login on the Framework Adapter. The Framework Adapter then determines whether or not the user is authorized to use Interstage BPM by matching the name and password that the user entered against the registered user list. If there is a match, the Framework Adapter returns a clientID variable. Since this random number is unique within the Framework Adapter, it can be used as a session ID, passing between the Server and the clients like a cookie.

Managing the Other Two Adapters: The Framework Adapter mediates between the Server, the DIR Adapter, and the DMS Adapter. When a user logs in, the Framework Adapter sends the clientID to both the DMS Adapter interface and the DIR Adapter interface. These two interfaces act as factories for the DMSSessionObject and the DirSessionObject respectively; however, they do not talk to the Server--only the Framework Adapter does.

The Framework Adapter creates and destroys these session objects for users who have successfully logged into the system through the DDFramework interface. More specifically, logging into the Interstage BPM server succeeds only if the DIRAdapter.createDirSession call and the DMSAdapter.createDMSSession return successfully. Logins can be verified any way deemed suitable. The session objects created are handles which provide access to the DMS and Directory services.

These session objects remain valid only while they have an active clientID. Since the Framework Adapter keeps track of the login status of the user, it is the entity that knows the longevity of these objects.

## Providing Security Through Impersonating the User

Interstage BPM's approach to providing security depends on both the environment and the operating system. One of the major things that will differ from environment to environment is how a DMS session object and a directory session object are created, using a client ID, a user ID or a user token. Because of this, the security capabilities and other attributes of the adapter will also differ. This is the chief reason that you must develop all of your integration adapters in tandem.

An example of this is Microsoft Windows 2000, which uses a similar method of authentication. When users log into Interstage BPM in this environment, they use the same login names and passwords as when they log into Microsoft Windows 2000. This information is then passed to Microsoft Windows 2000, which returns a userToken to the Framework Adapter. The Framework Adapter then passes it along to the Directory Adapter object and the DMS Adapter object.

The userToken is a session ID generated by Microsoft Windows 2000 that contains information about the user and password. The userToken variable has the purpose of connecting the user with a continuing session until the destroyDirSession method is called.

By using this identifier, Interstage BPM adapters impersonate the user(s), operating with the same privileges that the user or users have. In other words, when a user tries to do anything in Interstage BPM, the session objects acts on behalf of the user. So, impersonation lets the Interstage BPM program pretend to be a particular user, and by doing that, it can enforce the desired access privilege levels.

To maintain the communication link, the Framework Adapter then continues to talk to the Directory Adapter and DMS Adapter as if it was a user.

Although you will see userToken mentioned in this API, it is an internal variable that is not accessible to any custom adapters that you might be developing. In your implementation of Interstage BPM, the Server should never address the adapters directly, but should always communicate through the DDFramework. This means that you will never directly access the userToken variable.

You don't have to use the strategy of impersonation to use Interstage BPM if you have a different mechanism to take care of security issues. However, the Framework Adapter knows when a user logs in or out. If created without the Framework Adapter, access control and garbage collection is not easy to implement.

In talking to the Framework Adapter, Interstage BPM identifies any particular session in Interstage BPM through the use of another variable, the clientID. This variable will be much easier for you to access in creating your customized adapters.

## Recommended Method of Logging in on Microsoft Systems

The recommended method of using the Directory Adapter or the DMS Adapter is to first login by calling:

public long login(String userid, String password)

throws RemoteException, DdfOperationFailed

or

private native int ntLogin(String userid, String password);

These methods generate and return a unique variable called the clientId, the unique identifier for the login session with Interstage BPM. Then, the methods DDFramework.getDirObject and DDFramework.getDMSObject generate additional calls to the DMSAdapter and the DirAdapter to return the DirSessionObject and DMSSessionObject respectively. Besides supplying them with the clientID, it also supplies them with the userToken.

Thus, these methods can provide you with a handle to later use with such methods as DIRSessionObject.getEnumGroup( ).

The clientID is the session ID that is accessible to Interstage BPM developers, and that permits Interstage BPM to maintain the Interstage BPM session in the open Web environment. Interstage BPM uses both clientID and userToken with the methods DIRAdapter.createDIRSession( ) or DMSAdapter.createDMSSession( ) to enable these session objects to impersonate the user when performing operations on behalf of the user.

The DIRAdapter interface and the DMSAdapter interface are factories of DIRSessionObjects and DMSSessionObjects respectively, but they should only be called by DDFramework, which is constructed to provide the userToken and clientID variables to the DMSSessionObject and the DirSessionObject methods.

Later, you can access these objects by calling the following:

## DDFrameworkImpl.getDMSObject()

DDFrameworkImpl.getDirObject()

Warning: Never use methods that bypass the DDFramework, such as DIRAdapter.createDIRSession( ) or DMSAdapter.createDMSSession( ). Both of these methods require the internal userToken variable that you cannot access directly. The methods in this API that address userToken are only included for testing purposes.

Note: Logging in also generates RMI objects and logging out deactivates them and releases resources that were allocated to them. This process, however, is completely transparent to Interstage BPM developers and is managed entirely through Interstage BPM.

## Security on Sun Solaris Machines Through JNDI

Security options in Interstage BPM on Sun Solaris are different from the security options available in Microsoft Windows 2000. LDAP, for instance, does not use the concept of a session, nor is there any login function. LDAP simply operates through calls. If you wanted to implement all of Microsoft Windows 2000's access control policies in LDAP, you'd have to make some trade offs.

On a UNIX system, access control to the file system must be managed through Java, which does not have an impersonation API. Thus, without the access controls within Interstage BPM, users could do anything they wanted to do.

Overview | Package | Class | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES