PI16882: SINGLE SIGN ON NOT WORKING AS EXPECTED.

Download for IBM Worklight V6.1.0 Fix Pack 2
IBM Worklight Interim Fix README for 6.0.0.2

APAR status

• Closed as program error.

Error description

• Invalidated user session details are being incorrectly reused
  in the scenario involving more than one user and more than one
  application on Android or iOS device.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Multiple users who use the same device and use two or more   *
  * single sign-on applications on that device.                  *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * This problem occurs when a device is running two or more SSO *
  * applications. When the user identity is changed in one of    *
  * these applications (i.e a user logs out and another one logs *
  * in), other applications, which run in the background, remain *
  * logged-in as the previous user.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * -                                                            *
  ****************************************************************
  

Problem conclusion

• A change was made to Worklight server behavior when using SSO:
  
  - Applications returning from background are assigned the latest
  SSO user identity, if such exists.
  - This change to the user identity occurs on the server side. It
  is transparent to the client side of the application, unless
  explicitly checked.
  - The client-side application will not be updated or reloaded
  following the user identity change, and any data which was
  already loaded will remain as is. Note that if such actions are
  needed, the application developer is responsible to take them.
  
  When action is required on the client-side, the developer should
  should check for user identity changes. This can be done as
  follows:
  
  Javascript/hybrid applications - The developer should add an
  event listener for the "resume" event, and test for user
  identity changes.
  
  Example code:
  
  document.addEventListener("resume", function() {
   // Get the previous user id
   var userId = WL.Client.getLoginName(nameOfTheUserRealm);
   WL.Client.updateUserInfo({
    onSuccess: function() {
     // Get the new user id and compare
     var newUserId = WL.Client.getLoginName(nameOfTheUserRealm);
     if (userId != newUserId){
                                  alert("user has changed,
  reloading...");
      WL.Client.reloadApp();
     }
    }
  
                 onFailure: ...
   });
  }, false);
  
  
  Native- The developer needs to keep track of the previous user
  Id, and when resuming the application:
   1. Call connect()
   2. Parse the response json.
   3. Compare the userId to the previously stored one.
  
  Example code:
  
   @Override
   public void onResume(){
    super.onResume();
    wlclient.connect(new WLResponseListener() {
     @Override
     public void onSuccess(WLResponse response) {
      try {
       // Need to parse the JSON here:
       String userId = response.getResponseJSON()
           .getJSONObject("userInfo")
           .getJSONObject(nameOfTheUserRealm)
           .getString("userId");
  
       if (!userId.equals(thePreviousUserId)){
        // Do something with the data or reload the app...
       }
      } catch (JSONException e) {
       e.printStackTrace();
      }
     }
  
     @Override
     public void onFailure(WLFailResponse response) {
      ....
     }
    });
   }
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WORKLIGHT ENTER

• Fixed component ID

  5725I4300

Applicable component levels

• R600 PSY

     UP

• R610 PSY

     UP