Dan, Thanks. I appreciate you must be really tiring of this thread! This works correctly;
private WebServiceContext webServiceContext; @Resource public void setWebServiceContext(WebServiceContext webServiceContext) { this.webServiceContext = webServiceContext; } I think it would be nice to put all of this into a Wiki page given there are two distinct mechanisms of getting the Principal when a bean is exposed as a WS and REST service. John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com Daniel Kulp <[EMAIL PROTECTED]> 23/06/2008 17:53 Please respond to users@cxf.apache.org To users@cxf.apache.org cc Subject Re: Roles and permissions Right. The point is that JAX-WS will not inject a security context, ever. It's not a jax-ws concept. It will inject a WebServiceContext object which is a JAX-WS concept. From there, you can query the Principal and Roles using the JAX-WS api's. Regarding your other question, you should be able to use the Acegi/ SpringSecurity annotations and the acegi context listeners to accomplish that. Dan On Jun 23, 2008, at 10:46 AM, John-M Baker wrote: > Dan, > > I have done this: > > /** > * Retrieve an application configuration by id. > * > * Webservice method. > */ > Response getApplicationConfiguration(@PathParam("id") String id); > > /** > * Retrieve an application configuration by id. > * > * REST method. > */ > @GET > @Path("/get/{id}/") > @ProduceMime("application/xml") > @WebMethod(exclude = true) > Response getApplicationConfiguration(@PathParam("id") String id, > @Context SecurityContext sc); > > And in the implementation, the former calls the latter passing the > global > variable set from the setter method - which currently does not work. > Which > brings me back to the question on a timeline for when the setter > method > solution will work? > > Also, I see weblogic's WS implementation has a concept of > permissioning as > follows: > > @RolesAllowed([EMAIL PROTECTED](role=AUTHORIZE)}) > public boolean authorize(AuthorizeRequest request) { > > Would this be something CXF may support? Annotating methods with > roles > does seem a nice feature. I was just about to read the jax-ws > specificaiton to see if it mentioned this approach, but I'm sure you > guys > have a better idea! > > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > > > Daniel Kulp <[EMAIL PROTECTED]> > 23/06/2008 15:29 > Please respond to > users@cxf.apache.org > > > To > users@cxf.apache.org > cc > > Subject > Re: Roles and permissions > > > > > > > > You probably will need to split it into two methods, one that takes > the JAX-RS SecurityContext and one that doesn't and instead uses the > WebServiceContext. Probably the two of those would just pull the > required stuff out and pass them to a common third method that's only > in the impl, not the interface. > > Dan > > > On Jun 23, 2008, at 10:22 AM, John-M Baker wrote: > >> Yes!! Sorry, I missed this completely. >> >> Therefore shall I conclude there's no way of getting a >> SecurityContext for >> a WS call until a future release of CXF? >> >> >> John Baker >> -- >> Web SSO >> IT Infrastructure >> Deutsche Bank London >> >> URL: http://websso.cto.gt.intranet.db.com >> >> >> >> >> "Sergey Beryozkin" <[EMAIL PROTECTED]> >> 23/06/2008 15:13 >> Please respond to >> users@cxf.apache.org >> >> >> To >> <users@cxf.apache.org> >> cc >> <users@cxf.apache.org> >> Subject >> Re: Roles and permissions >> >> >> >> >> >> >> >>>> *********Shortly, the following form of injection will also be >> supported***** : >> >> Does it answer your question ? >> >> >> Cheers, Sergey >> >>>> >>>> @Context >>>> void setSecurityContext(SecurityContext sc) {} >>> >>> That doesn't work either due to a compile error: >>> >>> annotation type not applicable to this kind of declaration >>> [javac] @Context >>> [javac] ^ >>> [javac] 1 error >>> >>> Are you absolutely sure this setter logic will work through a REST >>> call? >> I >>> haven't tried a WS call yet, I'd like one solution for both types of >>> service. >>> >>> >>> John >>> >>>> About ServletContext : only @Resource annotated field of this type >>>> can be injected. @Context annotated fields of this type (and >>>> setters and parameters) will also be supported shortly. >>>> >>>> Cheers, Sergey >>>> >>>> >>>> >>>> >>>>> Sergey, >>>>> >>>>> To confirm, if I remove the Webservice configuration and >>>>> annotate a >>>>> parameter to a method, the SecurityContext is set as expected. >>>>> >>>>> So what i'm looking for is a solution for a bean exposed through >>>>> WS >>> and >>>>> REST, and given we can't expose a bean through a WS when a method >>>>> has >>> been >>>>> annotated, a setter seems the only way forward - but that >>>>> currently >>>>> doesn't work. >>>>> >>>>> >>>>> John Baker >>>>> -- >>>>> Web SSO >>>>> IT Infrastructure >>>>> Deutsche Bank London >>>>> >>>>> URL: http://websso.cto.gt.intranet.db.com >>>>> >>>>> >>>>> >>>>> >>>>> John-M Baker <[EMAIL PROTECTED]> >>>>> 23/06/2008 12:08 >>>>> Please respond to >>>>> users@cxf.apache.org >>>>> >>>>> >>>>> To >>>>> users@cxf.apache.org >>>>> cc >>>>> users@cxf.apache.org >>>>> Subject >>>>> Re: Roles and permissions >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sergey, >>>>> >>>>> Thanks for your feedback, and congratulations on the new 2.1.1. >>> release of >>>>> >>>>> CXF. I'm using this release I can not get access to the >>> ServletContext or >>>>> >>>>> SecurityContext within a bean when called via REST. Here's what >>>>> I've >>>>> added: >>>>> >>>>> private ServletContext sc; >>>>> >>>>> public void setServletContext(@Context ServletContext sc) >>>>> { this.sc = sc; } >>>>> >>>>> and >>>>> >>>>> private SecurityContext sc; >>>>> >>>>> public void setServletContext(@Context SecurityContext sc) >>>>> { this.sc = sc; } >>>>> >>>>> sc is null in both cases when a REST call is made. Are more >>> annotations >>>>> required? >>>>> >>>>> Any thoughts? >>>>> >>>>> >>>>> John Baker >>>>> -- >>>>> Web SSO >>>>> IT Infrastructure >>>>> Deutsche Bank London >>>>> >>>>> URL: http://websso.cto.gt.intranet.db.com >>>>> >>>>> >>>>> >>>>> >>>>> "Sergey Beryozkin" <[EMAIL PROTECTED]> >>>>> 23/06/2008 11:20 >>>>> Please respond to >>>>> users@cxf.apache.org >>>>> >>>>> >>>>> To >>>>> <users@cxf.apache.org> >>>>> cc >>>>> >>>>> Subject >>>>> Re: Roles and permissions >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yes, I don't remember offhand how, have a look at the JAX-WS docs >>> please, >>>>> I think it can be injected through a field or through a >>>>> setter. Perhaps using a setter is better in cases like this, as >>>>> you >>> can >>>>> then extract the common info from either JAX-WS >>>>> WebServiceContext or JAX-RS SecurityContext. >>>>> >>>>> Perhaps, in the future, things like SecurityContext in both JAX-WS >> and >>>>> JAX-RS can rely on some shared (CXF utility) code so that >>>>> they can be casted to a common class to be used by the >>>>> application... >>>>> >>>>> Cheers, Sergey >>>>> >>>>> ----- Original Message ----- >>>>> From: "John-M Baker" <[EMAIL PROTECTED]> >>>>> To: <users@cxf.apache.org> >>>>> Sent: Monday, June 23, 2008 9:36 AM >>>>> Subject: Re: Roles and permissions >>>>> >>>>> >>>>>> And how is that done? Via a set method of some kind? >>>>>> >>>>>> John Baker >>>>>> -- >>>>>> Web SSO >>>>>> IT Infrastructure >>>>>> Deutsche Bank London >>>>>> >>>>>> URL: http://websso.cto.gt.intranet.db.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Daniel Kulp <[EMAIL PROTECTED]> >>>>>> 20/06/2008 18:13 >>>>>> Please respond to >>>>>> users@cxf.apache.org >>>>>> >>>>>> >>>>>> To >>>>>> users@cxf.apache.org >>>>>> cc >>>>>> >>>>>> Subject >>>>>> Re: Roles and permissions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jun 20, 2008, at 11:23 AM, John-M Baker wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> What was the solution to this problem? Only apply it to the >>>>>>> REST >>>>>>> service? >>>>>>> Will a future release of CXF fix it for SOAP? >>>>>>> >>>>>> >>>>>> Well, JAX-WS has it's own security stuff. Thus, for jax-ws/ >>>>>> soap, >>>>>> you would need the WebServiceContext injected which has the >>> principal/ >>>>>> role on it. >>>>>> >>>>>> Dan >>>>>> >>>>> >>>>> ---------------------------- >>>>> IONA Technologies PLC (registered in Ireland) >>>>> Registered Number: 171387 >>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, >>> Ireland >>>>> >>>>> >>>>> >>>>> --- >>>>> >>>>> This e-mail may contain confidential and/or privileged >>>>> information. >> If >>> you >>>>> are not the intended recipient (or have received this e-mail in >> error) >>>>> please notify the sender immediately and delete this e-mail. Any >>>>> unauthorized copying, disclosure or distribution of the material >>>>> in >>> this >>>>> e-mail is strictly forbidden. >>>>> >>>>> Please refer to http://www.db.com/en/content/eu_disclosures.htm >>>>> for >>>>> additional EU corporate and regulatory disclosures. >>>>> >>>>> >>>>> --- >>>>> >>>>> This e-mail may contain confidential and/or privileged >>>> information. If you are not the intended recipient (or have >>>> received >>> this >>>>> e-mail in error) please notify the sender immediately and delete >>>> this e-mail. Any unauthorized copying, disclosure or distribution >>>>> of the material in this e-mail is strictly forbidden. >>>>> >>>>> Please refer to http://www.db.com/en/content/eu_disclosures.htm >>>> for additional EU corporate and regulatory disclosures. >>>> >>>> ---------------------------- >>>> IONA Technologies PLC (registered in Ireland) >>>> Registered Number: 171387 >>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, >>> Ireland >>> >>> >>> --- >>> >>> This e-mail may contain confidential and/or privileged information. >>> If >> you are not the intended recipient (or have received this >>> e-mail in error) please notify the sender immediately and delete >>> this >> e-mail. Any unauthorized copying, disclosure or distribution >>> of the material in this e-mail is strictly forbidden. >>> >>> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >> additional EU corporate and regulatory disclosures. >> >> ---------------------------- >> IONA Technologies PLC (registered in Ireland) >> Registered Number: 171387 >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, >> Ireland >> >> >> >> --- >> >> This e-mail may contain confidential and/or privileged information. >> If you are not the intended recipient (or have received this e-mail >> in error) please notify the sender immediately and delete this e- >> mail. Any unauthorized copying, disclosure or distribution of the >> material in this e-mail is strictly forbidden. >> >> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >> additional EU corporate and regulatory disclosures. > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > > > > --- > > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail > in error) please notify the sender immediately and delete this e- > mail. Any unauthorized copying, disclosure or distribution of the > material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.