Hi You might want to consider extending AbstractUsernameTokenAuthenticatingInterceptor [1] and override its createSubject(...) method *instead of* registering a callback with WSS4JInInterceptor. You'd only need a callback if UT is actually encrypted. Then register this custom interceptor instead of WSS4JInInterceptor. The subject should have the first Principal representing the actual authenticated user and other principals optionally representing Groups.
For example, see [2]. [2] actually extends UsernameTokenInterceptor (it is to address a WSDL/WS-policy first case) but the signature is the same. Then you just register it with an endpoint. Cheers, Sergey [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/AbstractUsernameTokenAuthenticatingInterceptor.java [2] http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java On Fri, Jul 23, 2010 at 9:39 AM, Antoine Roux <[email protected]>wrote: > Hi, > I have a web service authenticating with WS-Security. On the server side, I > set up the WSS4j interceptor and I have a password call back that checks > the > the username/password against my database. The service being called > subsequently if authentication succeeds needs to know the identity of the > user. > What is th right to pass it to the service? Is it to store it in the > session? Or is there a better way? > > -- > Antoine Roux, > NetVitesse S.A.R.L > [email protected] > Phone: +33 (0)1 61 37 04 24 > Mobile: +33 (0)6 20 69 07 96 > Fax: +33 (0)1 70 24 87 88 >
