That's the main difference is that I used Username Authentication with
Symmetric Keys technique as described in the following site:
http://docs.sun.com/app/docs/doc/820-1072/6ncp48v5d?a=view#ahiej
I want you to take note of the following:
1) This is NOT Basic Authentication.
2) The username/password pair specified in the client's
CallbackHandlerConfiguration xml element must belong in the application
server's default realm.
3) Even if you package your WAR in an EAR and declare the REALM, it
does not challenge against this realm, it only challenges against the
default realm.
3) If you move the Web Service into an EJB and package your application
in that manner, well Netbeans could not properly configure the client in
that scenario.
A quick experiment to verify this is:
1) remove your web application security constraints.
2) remove the client BASIC authentication code.
3) Implement Username Authentication with Symmetric Keys as explained in
http://docs.sun.com/app/docs/doc/820-1072/6ncp48v5d?a=view#ahiej
4) Put your WAR in an EAR. Declare your realm in your EAR. Declare
your Principle Role mappings in your sun-application.xml and sun-web.xml
If you do that, you'll see that the Application Server only authorizes
against the default realm, and that the Princple is not in the Web
Service Context.
Do you want me to provide the code?
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: Friday, November 09, 2007 8:16 AM
To: users_at_glassfish.dev.java.net
Subject: Re: UserPrinciple is null when utilizing Username
Authentication with Symme
Marco,
I just attempted to duplicate your test setup. I may not have done so,
so I'll recap what I did.
I created a Web module that implements a web service endpoint. Within
the service endpoint, I injected the WebServiceContext as shown below.
Then I configured the security properties of the endpoint url in
web.xml.
I defined the auth-method to be basic, and I defined an auth-constraint
on the endpoint url, permitting members of the "user" role.
I did not define a principal-2-Role mapping. Instead I activated the
default-principal-2-role mapping, which maps same named groups to same
named roles (which is described in
http://docs.sun.com/app/docs/doc/819-3672/beacr?l=ru&a=view)
I created a test user in the default realm, and assigned that user to
the "user" group.
I created a corresponding web service client and invoked it with the
appropriate values for the --user and --password options. As you can see
from the endpoint impl, the return value from the endpoint, is the value
it obtains by calling getUserPrincipal on the WebServiceContext. In my
test, the endpoint returned the principal as expected.
a possible explanation for why you are seeing a different result, is
that the client does not authenticate to the endpoint, unless it is
required to do so as a result of the endpoint url being protected by an
auth-constraint. If the url is not protected, the client will not
pro-actively authenticate to the endpoint.
I also used this test to confirm that I could assign a different user
repository/realm to the endpoint. I'll describe how I did that on your
other post.
Ron
/*
* PingWebService.java
*
* Created on November 8, 2007, 7:33 PM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/
package test;
import javax.annotation.Resource;
import javax.jws.WebService;
import javax.xml.ws.WebServiceContext;
/**
*
* @author monzillo
*/
@WebService()
public class PingWebService {
@Resource
private WebServiceContext ctx;
public String Ping(String ping) {
return "Principal: " + ctx.getUserPrincipal() + " echo: " +
ping;
}
}
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=244775
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net