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
[email protected]
To
[email protected]
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
> [email protected]
>
>
> To
> [email protected]
> 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
>> [email protected]
>>
>>
>> To
>> <[email protected]>
>> cc
>> <[email protected]>
>> 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
>>>>> [email protected]
>>>>>
>>>>>
>>>>> To
>>>>> [email protected]
>>>>> cc
>>>>> [email protected]
>>>>> 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
>>>>> [email protected]
>>>>>
>>>>>
>>>>> To
>>>>> <[email protected]>
>>>>> 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: <[email protected]>
>>>>> 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
>>>>>> [email protected]
>>>>>>
>>>>>>
>>>>>> To
>>>>>> [email protected]
>>>>>> 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.
