IBM Support

PI31064: ANTIXSRF AUTHENTICATOR THROWS EXCEPTION IN COMBINATION WITH LTPA AUTHENTICATION ON WEBSPHERE

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Problem Description :
    In Worklight version prior to 6.3 all adapter invocations are
    occurring in a non-managed thread-pools.
    Non-managed refers to the fact that the application server (in
    this case WebSphere) is not aware of the new thread spawning.
    WebSphere has built-in security mechanisms preventing leakage of
    information between threads that are owned by different users.
    
    the first adapter invocation (after the
    LTPA token cookie being injected by DataPower) is causing
    (through Worklight's WebSphereLoginModule) the main request
    thread to be associated with the identity that is given to it by
    the LTPA token, but the subsequent invocation of a different
    adapter is creating another thread that is not associated with
    the LTPA identity.
    Because the inner adapter invocation is using the default
    security test the AntiXSRF realm is being included as part of
    the pre-invocation authentication, this in turn causes the
    AntiXSRF check to try and access the main thread's session,
    which has been associated with the LTPA supplied identity,
    causing the following error:
    com.ibm.websphere.servlet.session.UnauthorizedSessionRequestExce
    ption: SESN0008E: A user authenticated as anonymous has
    attempted to access a session owned by
    user:10.2.163.83:389/UID=visa,cn=users,DC=MOI,DC=AE.
    
    
    Additional Keywords :
    LTPA,DATAPOWER
    
    
    Versions affected:
    6.x
    Initial impact :
    medium
    Local fix :
    No local fix provided
    

Local fix

  • no local fix provided
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * Administrators running Worklight on WebSphere (not Liberty)  *
    * using versions 6.0.x-6.2.x who have LTPA enabled and use     *
    * Adapters that invoke other adapters who are protected by the *
    * built in AntiXSRF realm (other custom realm types might also *
    * be affected)                                                 *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * In Worklight versions prior to 6.3 all adapter invocations   *
    * are occurring in a non-managed thread-pools.                 *
    * Non-managed refers to the fact that the application server   *
    * (in our case WebSphere) is not aware of the new thread       *
    * spawning.                                                    *
    * WebSphere has a built-in security mechanisms preventing      *
    * leakage of information between threads that are owned by     *
    * different users.                                             *
    * The first LTPA protected adapter invocation is causing       *
    * (through Worklight's WebSphereLoginModule) the request       *
    * thread to be associated with the identity that is given to   *
    * it by the LTPA token, but the subsequent invocation of a     *
    * different adapter is creating another thread that is not     *
    * associated with the LTPA identity.                           *
    * Because the default security test includes the AntiXSRF      *
    * realm and the second adapter invocation is using the         *
    * non-managed thread, the AntiXSRF realm is being included as  *
    * part of the pre-invocation authentication, this in turn      *
    * causes the AntiXSRF check to try and access the main         *
    * thread's session which has been associated with the LTPA     *
    * supplied identity, causing the WebSphere session security to *
    * throw an error due to the invoking thread having an          *
    * anonymous identity.                                          *
    * WebSphere throws the following error:                        *
    * com.ibm.websphere.servlet.session.UnauthorizedSessionRequest *
    * Exception: SESN0008E: A user authenticated as anonymous has  *
    * attempted to access a session owned by                       *
    * user:10.0.0.0:389/UID=demo,cn=users,DC=IBM,DC=IL.            *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * -                                                            *
    ****************************************************************
    

Problem conclusion

  • The session object is now propagated to adapter invocations
    occurring in spawned threads allowing the spawned threads to
    access the session without violating WebSphere's session
    security .
    No further action needs to be taken after installing the fix.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI31064

  • Reported component name

    WL/MFPF ENTERPR

  • Reported component ID

    5725I4300

  • Reported release

    506

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-12-08

  • Closed date

    2015-01-13

  • Last modified date

    2015-01-13

  • 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

    WL/MFPF ENTERPR

  • Fixed component ID

    5725I4300

Applicable component levels

  • R600 PSY

       UP

  • R610 PSY

       UP

  • R620 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSZH4A","label":"IBM Worklight"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"506","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
17 October 2021