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
