Thanks Dan. I noticed that I was putting in the password twice... but upon changing it.. AuthorizationPolicy is still null (the opName is working using your workaround).
Here is a tcpdump: POST /prototype_web/services/ProductSearchWebService HTTP/1.1 Content-Type: text/xml; charset=UTF-8 Authorization: Basic dm5ndXllbjpibGFjaw== SOAPAction: "" Accept: * Cache-Control: no-cache Pragma: no-cache User-Agent: Java/1.5.0_04 Host: ur-vnguyen.wynnesystems.com:8888 Connection: keep-alive Transfer-Encoding: chunked 1ca <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns1:g etProductInformation xmlns:ns1="http://webservices.ur.com";><companyCode xmlns:ns2="http://webservices.ur.com";></companyCode><itemNumber xmlns:ns2="http://webservices.ur.com";></itemNumber><stockClass xmlns:ns2="http://webservices.ur.com";></stockClass><countryCode xmlns:ns2="http://webservices.ur.com";></countryCode></ns1:getProductInfo rmation></soap:Body></soap:Envelope> 0 This is what my cxf.xml looks like for that endpoint: ><jaxws:endpoint id="productSearch" > implementor="com.ur.webservices.impl.ProductSearchImpl" > address="/ProductSearchWebService"> > <jaxws:inInterceptors> > <bean class="com.ur.webservices.security.AuthorizationInterceptor"/> > </jaxws:inInterceptors> ></jaxws:endpoint> I am using the standard way of passing in the username/password now: > BindingProvider bp = (BindingProvider)port; > bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "vnguyen"); > bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "mypassword"); Thanks, Van Nguyen United Rentals, Inc [EMAIL PROTECTED] (949) 225-6553 -----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 8:45 AM To: [email protected] Cc: Van Nguyen Subject: Re: Method level authentication? Van, On Tuesday 28 August 2007, Daniel Kulp wrote: > 2 parts: > 1) Issue of opName being null - I just checked the RPCInInterceptor > and it isn't setting a bunch of stuff that the DocLitInInterceptor is > setting. WSDL_OPERATION is one that it's not setting. :-( I'll > get those fixed tomorrow. Fixed this on trunk. However, there is a workaround: message.getExchange().get(OperationInfo.class) will get the OperationInfo object from which you can get the name. > 2) AuthorizationPolicy is null - not sure on that one. That is > provided but the transport if there is an Authorization header > present. Is there anyway you can TCPdump/wireshare the raw request > and see if there is an Authorization header? The code looks OK, > although I must admit I've never done it that way. I've always used > the standard JAX-WS API for setting the username/password for basic > auth: Figured this out. Your code is wrong: > > policy.setPassword("vnguyen"); > > policy.setPassword("myPassword"); You're setting the password twice. Thus, no username is being set. We don't put any basic auth stuff on the wire unless there is a username. Dan > > BindingProvider bp = (BindingProvider)port; > bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "BJ"); > bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "pswd"); > > Dan > > On Tuesday 28 August 2007, Van Nguyen wrote: > > Dan, > > > > I'm giving this a shot and am having some difficulties with the > > AuthorizationInterceptor finding the AuthorizationPolicy object. > > > > My Web Services looks something like this: > > > > @WebService(name = "productSearchService") > > @SOAPBinding(style = Style.RPC, use = Use.LITERAL) > > @WebFault(targetNamespace = "http://webservices.ur.com/types";, name > > = "productSearchException", faultBean = > > "com.ur.webservices.webfaults.ProductSearchServiceFault") > > @InInterceptors(interceptors={"com.ur.webservices.security.Authoriza > >ti on Interceptor"}) > > public interface ProductSearch > > { > > public Item getItem(String itemNumber) > > } > > > > Using the wsdl2java command, it created the java classes needed to > > call this web service: > > > > ProductSearchImplService ss = new > > ProductSearchImplService(wsdlURL, SERVICE_NAME); > > ProductSearchService port = ss.getProductSearchImplPort(); > > > > Client client = ClientProxy.getClient(port); > > HTTPConduit httpConduit = (HTTPConduit)client.getConduit(); > > AuthorizationPolicy policy = new AuthorizationPolicy(); > > policy.setPassword("vnguyen"); > > policy.setPassword("myPassword"); > > httpConduit.setAuthorization(policy); > > > > Calling port.getItem("1234"), brings me into the > > AuthorizationInterceptor... but both the AuthorizationPolicy and > > opName are null - I also assumed you meant to write: > > String opName = (String)message.get(Message.WSDL_OPERATION); > > > > Any ideas? > > > > Thanks, > > > > Van Nguyen > > United Rentals, Inc > > [EMAIL PROTECTED] > > (949) 225-6553 > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 28, 2007 10:27 AM > > To: [email protected] > > Cc: Van Nguyen > > Subject: Re: Method level authentication? > > > > > > Van, > > > > The answer is both yes and no. > > > > CXF doesn't have anything "built in" that would provide that > > capability. > > > > However, it would be very easy to write an interceptor that would: > > > > > > public class AuthorizationInterceptor extends > > AbstractPhaseInterceptor<Message> { > > > > public AuthorizationInterceptor() { > > super(Phase.USER_LOGICAL); > > } > > > > public void handleMessage(Message message) throws Fault { > > AuthorizationPolicy policy = > > message.get(AuthorizationPolicy.class); > > String opName = (String)message.put(Message.WSDL_OPERATION); > > > > //use username/passwords from AuthorizationPolicy to validate. > > //Throw a fault or similar if processing should not > > continue. } > > } > > > > > > There is also: > > message.get(SecurityContext.class); > > which can provide the principal object and checks for isUserInRole > > if your deployment environment (tomcat/etc...) supports > > configurations of users and roles on that level. > > > > Dan > > > > On Tuesday 28 August 2007, vannguyen0 wrote: > > > Hi, > > > > > > I'm fairly new to webservices and was wondering if CXF has the > > > ability to restrict users to certain web services methods. If I > > > have PerformProductSearch and UpdateProductInformation, I want to > > > allow user A (or users that is in user group A) permission to only > > > PerformProductSearch. But user B (or users that are in user group > > > B) can access to both methods. > > > > > > Thanks, > > > > > > Van -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
