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 !
Pinned topic Using DB2 trusted context on WAS AIX with Spring example ?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-02-03T07:43:10Z at 2012-02-03T07:43:10Z by NenadV
NenadV 2700023WA13 Posts
Re: Using DB2 trusted context on WAS AIX with Spring example ?2012-02-03T07:43:10ZThis is the accepted answer. This is the accepted answer.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).