IBM Support

PM70894: THE WS-SECURITY JAX-WS USERNAMETOKEN GENERATOR DOES NOT ACCEPT TOKENS THROUGH THE SHARED STATE

Fixes are available

7.0.0.27: WebSphere Application Server V7.0 Fix Pack 27
8.5.0.2: WebSphere Application Server V8.5 Fix Pack 2
8.0.0.6: WebSphere Application Server V8.0 Fix Pack 6
7.0.0.29: WebSphere Application Server V7.0 Fix Pack 29
8.0.0.7: WebSphere Application Server V8.0 Fix Pack 7
8.0.0.8: WebSphere Application Server V8.0 Fix Pack 8
7.0.0.31: WebSphere Application Server V7.0 Fix Pack 31
7.0.0.27: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.33: WebSphere Application Server V7.0 Fix Pack 33
8.0.0.9: WebSphere Application Server V8.0 Fix Pack 9
7.0.0.35: WebSphere Application Server V7.0 Fix Pack 35
8.0.0.10: WebSphere Application Server V8.0 Fix Pack 10
7.0.0.37: WebSphere Application Server V7.0 Fix Pack 37
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
7.0.0.39: WebSphere Application Server V7.0 Fix Pack 39
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
7.0.0.41: WebSphere Application Server V7.0 Fix Pack 41
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
7.0.0.43: WebSphere Application Server V7.0 Fix Pack 43
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
7.0.0.45: WebSphere Application Server V7.0 Fix Pack 45
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
7.0.0.27: Java SDK 1.6 SR12 Cumulative Fix for WebSphere Application Server
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • A fully-formed SAML token can be can be put in the sharedState
    by a login module and the SAMLConsumeLoginModule and/or
    SAMLGenerateLoginModule will use that token as if it were built
    by itself.  When you put a UsernameToken in the sharedState for
    use by the UNTConsumeLoginModule and/or UNTGenerateLoginModule
    the login modules are not recognizing the passed-in token.
    Passing a token into the UsernameToken login modules is
    necessary for proper operation of scenarios where the use of
    dynamic usernames and passwords are required.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  IBM WebSphere Application Server            *
    *                  developers of WS-Security enabled JAX-WS    *
    *                  applications                                *
    ****************************************************************
    * PROBLEM DESCRIPTION: The WS-Security UsernameToken           *
    *                      generator cannot accept an              *
    *                      application specified username and      *
    *                      password                                *
    ****************************************************************
    * RECOMMENDATION:  Install a fix pack that contains this       *
    *                  APAR.                                       *
    ****************************************************************
    A fully-formed SAML token can be can be put in the sharedState
    by a login module and the SAMLGenerateLoginModule will use
    that token as if it were built by itself.  This allows an
    application developer to build SAML tokens dynamically instead
    of having to use hardcoded values in the callback handler.
    Although you can dynamically pass a username and password to
    the UNTGenerateLoginModule when using WSSAPIs, if you must use
    policy sets and bindings, there is no way to pass dynamic
    information to the UsernameToken generator.
    

Problem conclusion

  • The WS-Security runtime is updated to allow an application
    developer to either dynamically set the username and password
    that the UNTGenerateLoginModule uses when generating a token.
    
    Two new methods are added to
    com.ibm.websphere.wssecurity.wssapi.token.GenericSecurityTokenFa
    ctory
    
    UsernameToken getSimpleUsernameToken(String username);
    UsernameToken getSimpleUsernameToken(String username, char[]
    password);
    
    
    An application developer can pass custom data to the
    UNTGenerateLoginModule in two ways in this priority order:
    
    1) From the sharedState from a stacked JAAS login module
    2) From the com.ibm.wsspi.wssecurity.token.tokenHolder list
    on the message context
    
    Refer to the following constants in
    com.ibm.wsspi.wssecurity.core.Constants for more information:
    
    com.ibm.wsspi.wssecurity.token.tokenHolder
    com.ibm.wsspi.wssecurity.token.enableCaptureTokenContext
    
    An application developer can change the username and password
    that is used by UNTGenerateLoginModule when generating an
    UsernameToken.  When a simple UsernameToken has been provided
    for use by UNTGenerateLoginModule, it will override what is
    configured in the callback handler.
    
    Following is an example of code that would go in a stacked
    login module in the login() method to override the username
    and password.  _sharedState comes from the first Map parameter
    on the initialize method in the login module.
    
    import
    com.ibm.websphere.wssecurity.wssapi.token.GenericSecurityTokenFa
    ctory;
    import com.ibm.websphere.wssecurity.wssapi.token.UsernameToken;
    
    public boolean login() throws LoginException {
    //get the factory
    GenericSecurityTokenFactory factory =
    GenericSecurityTokenFactory.getInstance();
    
    UsernameToken unt = factory.getSimpleUsernameToken("username",
    "password");
    
    factory.putGeneratorTokenToSharedState(_sharedState, unt);
    
    return true;
    }
    
    
    UNTConsumeLoginModule has also been updated so that an
    UsernameToken that is consumed is available on the shared
    state for use by a stacked login module.  The token can be
    obtained with the following method from the
    GenericSecurityTokenFactory:
    
    SecurityToken token =
    getConsumerTokenFromSharedState(_sharedState,
    com.ibm.websphere.wssecurity.wssapi.token.UsernameToken.ValueTyp
    e);
    
    This allows stacked login modules to now authenticate the
    username and password consumed by the UNTConsumeLoginModule,
    when they couldn't before.
    
    If you want to configure a JAAS login module stacked under
    UNTConsumeLoginModule to authenticate the username and
    password, do the following:
    
    set the following property on the configured callback handler:
    
    com.ibm.wsspi.wssecurity.token.UsernameToken.authDeferred=true
    
    Stack a jaas login module under
    com.ibm.ws.wssecurity.wssapi.token.impl.UNTConsumeLoginModule
    that does the following:
    
    1. Get the UsernameToken consumed by the UNTConsumeLoginModule
    with the following method:
    
    UsernameToken unt =
    (UsernameToken)factory.getConsumerTokenFromSharedState(sharedSta
    te,UsernameToken.ValueType);
    
    Where factory is an instance of
    com.ibm.websphere.wssecurity.wssapi.token.GenericSecurityTokenFa
    ctory
    
    2. Check the username and password in the manner that you
    choose.  You can call unt.getUsername() and unt.getPassword()
    to get the username and password.
    
    3. Put the SAME UsernameToken obtained in the step #1 above
    back onto the shared state with this method:
    
    factory.putAuthenticatedTokenToSharedState(sharedState, unt);
    
    If the UNTConsumeLoginModule does not find the UsernameToken
    that it had consumed in the proper location in the shared
    state, it will assume that the token has not been verified and
    will throw a LoginException.  This means that you cannot just
    set
    com.ibm.wsspi.wssecurity.token.UsernameToken.authDeferred=true
    on the callback handler without having an accompanying login
    module to also return the token to the shared state.
    
    
    The fix for this APAR is currently targeted for inclusion in
    fix pack 7.0.0.27, 8.0.0.6, 8.5.0.2.  Please refer to the
    Recommended Updates page for delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM70894

  • Reported component name

    WEBSPHERE APP S

  • Reported component ID

    5724J0800

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-08-14

  • Closed date

    2012-10-15

  • Last modified date

    2012-10-15

  • 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

    WEBSPHERE APP S

  • Fixed component ID

    5724J0800

Applicable component levels

  • R700 PSY

       UP

  • R800 PSY

       UP

  • R850 PSY

       UP



Document information

More support for: WebSphere Application Server
General

Software version: 8.0

Reference #: PM70894

Modified date: 15 October 2012