cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John-M Baker <john-m.ba...@db.com>
Subject Re: Roles and permissions
Date Mon, 23 Jun 2008 11:27:23 GMT
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 <john-m.baker+external@db.com> 
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" <sergey.beryozkin@iona.com> 
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" <john-m.baker@db.com>
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 <dkulp@apache.org>
> 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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message