Thank you very much for the reply !

I found the answer as well, but yours is more complete :-)

@Resource
private WebServiceContext context;

 public java.lang.String greetMe(java.lang.String inparameter) {
        LOG.info("Executing operation greetMe");

        Principal p = context.getUserPrincipal();
        if (p != null) {
            System.out.println("p.getName() = " + p.getName());
        }
        return new java.lang.String("Hi " + inparameter);
    }



Your a life saver !


On Fri, Dec 4, 2009 at 10:52 AM, Paweł Lipka <[email protected]> wrote:

> Hi,
>
> Try using the javax.xml.ws.WebServiceContext.getUserContext().
> You can get the WebServiceContext instance injected to your SEI
> implementation by annotating a proper setter method with a @Resource
> annotation.
>
> The WebServiceContext implementation is based on a ThreadLocal so you'll
> have the information corresponding to the currently processed SOAP request
> in the injected instance.
>
> if you're using UsernameToken WS-Security profile you'll find that the
> principal obtained from the getUserContext() is of type:
> org.apache.ws.security.WSUsernameTokenPrincipal
>
> hope this helps.
>
>
>
>
> Guy wrote:
>
>> Hi,
>>
>> I have a problem for which the answer escapes me. I am using CXF to deploy
>> a
>> webservice in an embedded Jetty webserver (extending the
>> CXFNonSpringServlet). I am also performing username/password
>> authentication
>> (implementing the CallbackHandler). The problem is that when invoking the
>> web service implementation, I need that username to see if the user is
>> authorised to perform the task.
>>
>> Any ideas on how to achieve this?
>>
>> I would think that the way to handle this problem is to use the session of
>> the request, but in the CallbackHandler (here I have the username) there
>> is
>> no way to retrieve the request. The same for the web service. Once you are
>> in the implementation bean of the webservice, there is no way to reach the
>> request, or the session associated with the request.
>>
>> The alternative is to implement operations/methods that always sent the
>> username/password and let the web service do the
>> authentication/authorisation all by itself, but I prefer not using this
>> solution...
>>
>> any help would be appreciated !
>>
>> kind regards
>>
>> Guy
>>
>>
>
> --
> Paweł Lipka
> Senior IT Architect
> AMG.net, A Bull Group Company
> ul. Łąkowa 29
> 90-554 Łódź
> tel.: (+48 42) 634 56 78
> www.amg.net.pl
>
> Treść niniejszej wiadomości może być poufna.
> Jeżeli nie jesteście Państwo jej adresatem, to rozprowadzanie
> lub wykorzystywanie zawartych tu informacji jest zabronione.
>
> This e-mail contains material that is confidential for the sole
> use of the intended recipient. Any review, reliance or distribution
> by others or forwarding without express permission is strictly
> prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>

Reply via email to