You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Davide Gesino <wi...@libero.it> on 2008/02/27 09:57:36 UTC

WebServiceContext Principal

According to the javadoc of WebServiceContext class,


getUserPrincipal() Returns the Principal that identifies the sender of the
request currently being serviced. If the sender has not been authenticated,
the method returns null.

how is supposed to be filled this Principal?
When?
By whom?
-- 
View this message in context: http://www.nabble.com/WebServiceContext-Principal-tp15708867p15708867.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: WebServiceContext Principal

Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 27 February 2008, Davide Gesino wrote:
> According to the javadoc of WebServiceContext class,
>
>
> getUserPrincipal() Returns the Principal that identifies the sender of
> the request currently being serviced. If the sender has not been
> authenticated, the method returns null.
>
> how is supposed to be filled this Principal?
> When?
> By whom?

Well, that's kind of application specific.   When running inside a 
servlet engine and using the CXFServlet, the CXFServlet provides an 
implementation that makes the getUserPrincipal() call back onto the same 
method of the current HttpServletRequest.   Thus, it's filled in by 
tomcat from the information tomcat knows about.  (like tomcat-users.xml 
in the tomcat conf directory along with information in the web.xml)

HOWEVER, if you have some sort of custom CXF interceptor, you can create 
your own org.apache.cxf.security.SecurityContext object that does 
whatever custom thing you need and set that in the message and then the 
calls to the WebServiceContext getUserPrincipal stuff will go through 
that. 

Ideally, the ws-security stuff would also set a new SecurityContext or 
similar with the information it has.   I'm not sure if it has a 
principal or role information right now or not.  

-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog