Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
1 reply Latest Post - ‏2012-02-03T07:43:10Z by NenadV
NenadV
NenadV
3 Posts
ACCEPTED ANSWER

Pinned topic Using DB2 trusted context on WAS AIX with Spring example ?

‏2012-02-01T08:11:12Z |
Hello,
need an example (of a reference) of using DB2 trusted context on WAS AIX connecting to DB2 for z/OS . Additionally our developers are using Spring framework and the end user identity is obtained from LTPA cookie :
.
.

uniqueId = com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validateLTPAToken(ltpaCookieBytes);

distinguishedName = com.ibm.wsspi.security.token.WSSecurityPropagationHelper.getUserFromUniqueID(uniqueId);
.
.

and they would like to have "out of the box " application security with minimal footprint of the security code in the application it self ( WAS container and the Spring configuration should provide security services).

Any help would be highly appreciated !

Regards,
Nenad
Updated on 2012-02-03T07:43:10Z at 2012-02-03T07:43:10Z by NenadV
  • NenadV
    NenadV
    3 Posts
    ACCEPTED ANSWER

    Re: Using DB2 trusted context on WAS AIX with Spring example ?

    ‏2012-02-03T07:43:10Z  in response to NenadV
    To rephrase my question :

    is it possible to use DB2 trusted context ( with switching user IDs)
    by using declarative security (in a transparent way for the developers)
    or the only way is to setting usrID for connection in the WAS application code it self?

    According to this article, user IDs must be handled in appl. code :

    Implicit versus explicit trusted connections

    Once a trusted context is defined and enabled, users can initiate a
    trusted connection explicitly or implicitly. An implicit trusted
    connection is one that is not explicitly requested. The implicit
    trusted connection results from a normal connection request that meets
    the requirements of an enabled trusted context. With an implicit
    trusted connection, the requestor can only acquire additional
    privileges through the role inheritance feature; they cannot switch the
    user ID. An implicit trusted connection requires no code changes. On
    the other hand, an explicit trusted connection is just that it is
    explicitly requested in the application code. The initiator of an
    explicit trusted connection has the ability to switch the current user
    ID on the connection to a different user ID with or without
    authentication as well as acquire additional privileges through the
    role inheritance feature. Roles may be inherited through the default
    role for the trusted context, or the role defined for the user. If an
    implicit trusted connection cannot be established, a normal connection
    is attempted. When an explicit trusted connection is requested, but the
    qualifications are not met, a regular connection is established, but a
    warning message is returned to the client (SQL code 20360).

    http://www.ibm.com/developerworks/data/library/techarticle/dm-0803eakle/