Ultra Light Client Guide and Reference

How to Write a ULC Reconnect Token Strategy

Writing Strategies Where the Token Identifies a User

This section discusses the normal case where the token is used to find out which contexts belong to a specific user. To prevent to user from getting the same application more than once, the framework internally adds the application name to the token. This is needed because if a connection to a (physical) server fails for some time the UI might try to reconnect to all its contexts (i.e. applications).

Since the reconnect feature allows the UI Engine to reconnect to an existing context with potentially secret business data it is important to have a secure ULC reconnect token strategy. Therefore the strategies contained in the release should only be used as examples. If using a symmetric encryption algorithm (as within XXX) keep in mind that it will not be very hard for an enemy to reverse engineer the Java part (i.e. UI proxy of the strategy). If the company's underlying infrastructure (middleware) identifies and knows the user of the connection then the easiest and most secure implementation would be to identify the user on the server side without a UI round trip to ask the user for name and password.

To write the new strategy a new subclass of UlcReconnectTokenStrategy must be made and the getToken private method must be implemented: This method must return a String which is used when a user wants to reconnect to disconnected contexts. Normally this token identifies a user. If the server can identify the user then it can return its ID/token directly; otherwise a request must be sent to the UI to query the user for name and password.

getToken
	  | challenge |
 
	  challenge := self nextRandomNumber.
	  ^self
	    decrypt: (self context getUIReconnectTokenWithStrategy: self withChallenge: challenge printString)
	    usingChallenge: challenge
 

The above example makes a call to the UI to ask for user name and password. This is always done using theUlcContext>>#getUIReconnectTokenWithStrategy:withChallenge: method. Get the token used for client reconnection from the UI using the specified strategy and the optional challenge (which can be used for encryption). This method must only be used by UlcReconnectTokenStrategy subclasses. This request is executed synchronously.

If user interaction is involved (eg entering name and password) then the typeString private method must be implemented too: Return the String that should be used as my identifier in all requests to the UI. Of course this method need only be implemented if the strategy sends requests to the UI.

typeString
	  ^'com.ibm.ulc.ui.UserPasswordTokenStrategy'
 
Note:
The string must be the class name of the fully qualified UI proxy class.

Writing the UI Proxy of a Strategy

There are four things to keep in mind:

  1. If your middleware on the server offers to retrieve the user of the current connection then use this information and don't go to the UI at all.
  2. The UI proxy for the strategy must implement the interface IReconnectTokenStrategy. The only method that comes with this interface is getToken(String) which is responsible to return a token for the given (optional) challenge String. This method must query the user for name and password (or something else to get a token) and then (if desired) encrypt the token eventually using the challenge string.
  3. The UI proxy must inherit from UIProxy.
  4. Make sure that MyTokenStrategy>>#typeString returns the fully qualified class name of the corresponding UI proxy class.

Writing other Types of Strategies

This section describes the methods involved if strategies different from the ones above need to be implemented.

isContextToken:sameAsUserToken:
This method must return a Boolean which is used when the two tokens are compared. A subclass may override this method to implement a strategy based on user/group permissions (e.g. a special user might see all hanging contexts). Together with getToken (see above) it is the most common method used to implement the ULC reconnect token strategy.

The next two methods must be kept in sync because they are used to get the token enriched with the application name. Normally the framework attaches the application name to the token that getToken returns. If you want to change the scope of the reconnect dialog, e.g. showing all hanging applications (in that server process/image) for a user without looking at the application name, you can do it by overwriting these two methods:

Note:
Normally these two methods should not be changed.

computeTokenFrom: aTokenString for: anAppName
This method extracts the original token (getToken) using the given aTokenString (normally taken from another context) and then enriches it with anAppName.

getTokenFor:anAppName
Returns a token which is used when a user wants to reconnect to disconnected contexts. Normally this token identifies a user and the anAppName to which the user wants to connect initially.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]