You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by John-M Baker <jo...@db.com> on 2008/06/17 11:36:33 UTC
Roles and permissions
Hello,
Is there any way to use annotations to apply roles to methods in a
Webservice or REST call? I'd like to be able to configure an application
to let users within one group access a set of methods that another set of
users can not access.
Is there a way to get the HttpRequest object from a method?
Thanks,
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
---
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.
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Hi,
Is there any more documentation on this? Or some examples? Or is it as
simple as:
public void myMethod(String param1, String param2, @Context
SecurityContext sc) {
..
}
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
17/06/2008 16:04
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
Subject
Re: Roles and permissions
Hi John
Try
@Context SecurityContext sc
as a parameter in your method
and then sc.isUsertInRole()...
The other option is to experiment with Acegi (Spring Security), as far as
applying permissions to individual methods - I haven't
tried myself. I think JAX-RS will support some explicit EE security
annotations too at some time
Cheers, Sergey
> Hello,
>
> Is there any way to use annotations to apply roles to methods in a
> Webservice or REST call? I'd like to be able to configure an
application
> to let users within one group access a set of methods that another set
of
> users can not access.
>
> Is there a way to get the HttpRequest object from a method?
>
> Thanks,
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
> ---
>
> 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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I'm confused by this stack trace
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
> counts of IllegalAnnotationExceptions
> javax.ws.rs.core.SecurityContext is an interface, and JAXB can't handle
> interfaces.
> this problem is related to the following location:
> at javax.ws.rs.core.SecurityContext
> at private javax.ws.rs.core.SecurityContext
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
> So it doesn't work or I'm doing it wrong:
>
> @GET
> @Path("/get/{id}/")
> @ProduceMime("application/xml")
> Response getApplicationConfiguration(@PathParam("id") String id,
> @Context SecurityContext sc);
>
> Any other thoughts?
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <se...@iona.com>
> 18/06/2008 10:37
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
> <us...@cxf.apache.org>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> I'm sorry, it's a lack of the docs...
>
> Please use the SecurityContext from a jaxrs package
> javax.ws.rs.core
> Hope it will work
>
> Cheers, Sergey
>
> ----- Original Message -----
> From: "John-M Baker" <jo...@db.com>
> To: <us...@cxf.apache.org>
> Cc: <us...@cxf.apache.org>
> Sent: Wednesday, June 18, 2008 10:13 AM
> Subject: Re: Roles and permissions
>
>
>> Sergey,
>>
>> Using @Context SecurityContext sc didn't work:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
>> handle interfaces.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>> org.apache.cxf.security.SecurityContext does not have a no-arg default
>> constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> And the SecurityContextImpl didn't work either:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a no-arg
>> default constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.jaxrs.provider.SecurityContextImpl
>> at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> Any thoughts?
>>
>>
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>>
>>
>> "Sergey Beryozkin" <se...@iona.com>
>> 17/06/2008 16:04
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> <us...@cxf.apache.org>
>> cc
>>
>> Subject
>> Re: Roles and permissions
>>
>>
>>
>>
>>
>>
>> Hi John
>>
>> Try
>>
>> @Context SecurityContext sc
>>
>> as a parameter in your method
>>
>> and then sc.isUsertInRole()...
>>
>> The other option is to experiment with Acegi (Spring Security), as far
> as
>> applying permissions to individual methods - I haven't
>> tried myself. I think JAX-RS will support some explicit EE security
>> annotations too at some time
>>
>> Cheers, Sergey
>>
>>
>>> Hello,
>>>
>>> Is there any way to use annotations to apply roles to methods in a
>>> Webservice or REST call? I'd like to be able to configure an
>> application
>>> to let users within one group access a set of methods that another set
>> of
>>> users can not access.
>>>
>>> Is there a way to get the HttpRequest object from a method?
>>>
>>> Thanks,
>>>
>>>
>>> John Baker
>>> --
>>> Web SSO
>>> IT Infrastructure
>>> Deutsche Bank London
>>>
>>> URL: http://websso.cto.gt.intranet.db.com
>>>
>>>
>>> ---
>>>
>>> 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.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Or are you saying that the only way to get a Security/Servlet Context via
REST is through a parameter to the method, and the only way to get it via
a WS is through a setter?
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
23/06/2008 11:20
Please respond to
users@cxf.apache.org
To
<us...@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" <jo...@db.com>
To: <us...@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 <dk...@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.
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Sergey,
Thanks, I'll go through this now. May I ask, will there be any attempt to
solve the WS problem where by the SecurityContext can not be passed in a
method? This was the cause of the exception I pasted at the start of the
discussion - it would certainly make life simplier if both REST and WS
supported this formality.
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
23/06/2008 14:22
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
<us...@cxf.apache.org>
Subject
Re: Roles and permissions
Hi
Did you try to exclude a method from a JAX-Ws inrospection mechanism, as
Dan suggested earlier, for ex, one way is to add
@WebMethod(exclude = true) to this method. It should work without you
removing the jaxws-config.
By the way, in your sample
> public void setServletContext(@Context SecurityContext sc)
> { this.sc = sc; }
you should probaly change it to setSecurityContext().
Having a given @Context-annotated field of type SecurityContext should
also work - it's not thread safe though at the moment.
Shortly, the following form of injection will also be supported :
@Context
void setSecurityContext(SecurityContext sc) {}
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 <jo...@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" <se...@iona.com>
> 23/06/2008 11:20
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@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" <jo...@db.com>
> To: <us...@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 <dk...@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.
----------------------------
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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi John
Agreed, it would be worth documenting on how to access the context infomation when combining JAX-WS and JAX-RS. There're 2 variations but the advice would be probably the same.
Case 1. JAX-WS invocation is mapped to methodA, while JAX-RS invocation is mapped to methodB.
For ex :
void doJaxWs(String a);
void doJaxRs(String a);
Probably the main reason these two methods exist is that it's not possible to reuse the same method (signature) between both JAX-WS and JAX-RS invocations.
In cases like this what was suggested on this thread (inexplicitly sometimes) is to do something like this :
@Resource
public void setWebServiceContext(WebServiceContext webServiceContext) {
this.webServiceContext = webServiceContext;
}
void doJaxWs(String a) {
verify(getSecurityInfoFromJaxWsContext(webServiceContext));
....
}
@WebMethod(exclude = true)
void doJaxRs(String a, @Context SecurityContext sc) {
verify(getSecurityInfoFromJaxRsContext(sc));
}
Note if this latter method is invoked directly by JAX-RS runtime, the context will be set as a parameter properly.
private void verify(SecurityInfo si) throws SecurityException {}
private static class SecurityInfo {
Principal getPrincipal() {...}
boolean isUserInRole() {...}
}
The same applies to all other types of context information.
Few notes about this method :
@WebMethod(exclude = true)
void doJaxRs(String a, @Context SecurityContext sc) {
verify(getSecurityInfoFromJaxRsContext(sc));
}
As I said earlier, quite soon it will be possible, for JAX-RS, to inject the same context info either into fields or through setters :
@Context SecurityContext sc;
or
@Context
setSecurityContext(SecurityContext sc) {}
Note what is said above still applies, as these forms of injection in JAX-RS are there simply to let developers not to put @Context annotated parameters into the resource methods invoked by JAX-RS as they might come as part of the existing interface, etc.
2. Sometimes, it can be possible to have the same method serve both JAX-WS and JAX-RS invocations, without creating method pairs. In cases like these the best way to extract some specific context info available in both JAX-WS and JAX-RS contexts is again rely on the technique suggested above, where the common info is extracted into a seperate utility class. The only difference here is that the injection of JAX-RS contexts through parameters can not be supported.
Hope it helps. And thanks for experimenting...
Cheers, Sergey
> 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
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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 <dk...@apache.org>
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({@SecurityRole(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 <dk...@apache.org>
> 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" <se...@iona.com>
>> 23/06/2008 15:13
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> <us...@cxf.apache.org>
>> cc
>> <us...@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 <jo...@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" <se...@iona.com>
>>>>> 23/06/2008 11:20
>>>>> Please respond to
>>>>> users@cxf.apache.org
>>>>>
>>>>>
>>>>> To
>>>>> <us...@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" <jo...@db.com>
>>>>> To: <us...@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 <dk...@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.
>>>>
>>>> ----------------------------
>>>> 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
> dkulp@apache.org
> 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
dkulp@apache.org
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.
Re: Roles and permissions
Posted by Daniel Kulp <dk...@apache.org>.
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({@SecurityRole(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 <dk...@apache.org>
> 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" <se...@iona.com>
>> 23/06/2008 15:13
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> <us...@cxf.apache.org>
>> cc
>> <us...@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 <jo...@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" <se...@iona.com>
>>>>> 23/06/2008 11:20
>>>>> Please respond to
>>>>> users@cxf.apache.org
>>>>>
>>>>>
>>>>> To
>>>>> <us...@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" <jo...@db.com>
>>>>> To: <us...@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 <dk...@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.
>>>>
>>>> ----------------------------
>>>> 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
> dkulp@apache.org
> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
I should probably also ask if CXF supports:
import javax.annotation.security.RolesAllowed;
@RolesAllowed("ADMIN")
At first glance, it doesn't seem to - but if this does work then I don't
need to get the securitycontext..
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
John-M Baker <jo...@db.com> wrote on 23/06/2008 15:46:36:
> 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({@SecurityRole(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 <dk...@apache.org>
> 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" <se...@iona.com>
> > 23/06/2008 15:13
> > Please respond to
> > users@cxf.apache.org
> >
> >
> > To
> > <us...@cxf.apache.org>
> > cc
> > <us...@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 <jo...@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" <se...@iona.com>
> >>>> 23/06/2008 11:20
> >>>> Please respond to
> >>>> users@cxf.apache.org
> >>>>
> >>>>
> >>>> To
> >>>> <us...@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" <jo...@db.com>
> >>>> To: <us...@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 <dk...@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.
> >>>
> >>> ----------------------------
> >>> 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
> dkulp@apache.org
> 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.
---
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.
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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({@SecurityRole(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 <dk...@apache.org>
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" <se...@iona.com>
> 23/06/2008 15:13
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
> <us...@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 <jo...@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" <se...@iona.com>
>>>> 23/06/2008 11:20
>>>> Please respond to
>>>> users@cxf.apache.org
>>>>
>>>>
>>>> To
>>>> <us...@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" <jo...@db.com>
>>>> To: <us...@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 <dk...@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.
>>>
>>> ----------------------------
>>> 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
dkulp@apache.org
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.
Re: Roles and permissions
Posted by Daniel Kulp <dk...@apache.org>.
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" <se...@iona.com>
> 23/06/2008 15:13
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
> <us...@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 <jo...@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" <se...@iona.com>
>>>> 23/06/2008 11:20
>>>> Please respond to
>>>> users@cxf.apache.org
>>>>
>>>>
>>>> To
>>>> <us...@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" <jo...@db.com>
>>>> To: <us...@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 <dk...@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.
>>>
>>> ----------------------------
>>> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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" <se...@iona.com>
23/06/2008 15:13
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
<us...@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 <jo...@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" <se...@iona.com>
>> > 23/06/2008 11:20
>> > Please respond to
>> > users@cxf.apache.org
>> >
>> >
>> > To
>> > <us...@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" <jo...@db.com>
>> > To: <us...@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 <dk...@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.
>>
>> ----------------------------
>> 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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
>> *********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 <jo...@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" <se...@iona.com>
>> > 23/06/2008 11:20
>> > Please respond to
>> > users@cxf.apache.org
>> >
>> >
>> > To
>> > <us...@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" <jo...@db.com>
>> > To: <us...@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 <dk...@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.
>>
>> ----------------------------
>> 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
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Sergey,
> you should probaly change it to setSecurityContext().
It doesn't work.
> Having a given @Context-annotated field of type SecurityContext
> should also work - it's not thread safe though at the moment.
> Shortly, the following form of injection will also be supported :
>
> @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 <jo...@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" <se...@iona.com>
> > 23/06/2008 11:20
> > Please respond to
> > users@cxf.apache.org
> >
> >
> > To
> > <us...@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" <jo...@db.com>
> > To: <us...@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 <dk...@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.
>
> ----------------------------
> 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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Did you try to exclude a method from a JAX-Ws inrospection mechanism, as Dan suggested earlier, for ex, one way is to add
@WebMethod(exclude = true) to this method. It should work without you removing the jaxws-config.
By the way, in your sample
> public void setServletContext(@Context SecurityContext sc)
> { this.sc = sc; }
you should probaly change it to setSecurityContext().
Having a given @Context-annotated field of type SecurityContext should also work - it's not thread safe though at the moment.
Shortly, the following form of injection will also be supported :
@Context
void setSecurityContext(SecurityContext sc) {}
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 <jo...@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" <se...@iona.com>
> 23/06/2008 11:20
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@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" <jo...@db.com>
> To: <us...@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 <dk...@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.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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 <jo...@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" <se...@iona.com>
23/06/2008 11:20
Please respond to
users@cxf.apache.org
To
<us...@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" <jo...@db.com>
To: <us...@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 <dk...@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.
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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" <se...@iona.com>
23/06/2008 11:20
Please respond to
users@cxf.apache.org
To
<us...@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" <jo...@db.com>
To: <us...@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 <dk...@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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
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" <jo...@db.com>
To: <us...@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 <dk...@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
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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 <dk...@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
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> Daniel Kulp <dk...@apache.org>
> 18/06/2008 14:43
> Please respond to
> users@cxf.apache.org
>
>
> To
> users@cxf.apache.org
> cc
>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
>
> On Jun 18, 2008, at 9:38 AM, Sergey Beryozkin wrote:
>
>> Hi,
>>
>> If so then I'd assuem it's something which needs to be fixed in a
>> jaxws asm processor, as this method
>>
>>>> Response getApplicationConfiguration(@PathParam("id") String id,
>>>> @Context SecurityContext sc);
>>
>> is unlikely to be part of whatever interface the JAX-WS endpoint
>> supports ?
>> Dan, what do you reckon ? Is it possible to push the methods to be
>> invoked over SOAP to a seperate interface so that the other methods
>> are not introspected on the implementation class itself ?
>
> Yes. The endpointInterface attribute on the WebService annotation
> would give us the interface that we would use.
>
> Alternatively, just add:
> @WebMethod(exclude = true)
> to the methods you don't want JAX-WS to look at.
>
> Dan
>
>
>
>>
>>
>> John, you can also try annotating a field instead
>>
>> @Context
>> private SecurityContext sc;
>>
>> Note it's not thread-safe but it will be fixed shorly
>>
>> Cheers, Sergey
>>
>>> Yes, I do.
>>>
>>> <!-- Define the REST service -->
>>> <jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
>>> address="/rest">
>>> <jaxrs:serviceBeans>
>>> <ref bean="service.beans.applicationConfiguration" />
>>> </jaxrs:serviceBeans>
>>> </jaxrs:server>
>>>
>>> <!-- Define the application configuration webservice -->
>>> <jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
>>> implementor="#service.beans.applicationConfiguration"
>>> address="/soap/applicationConfiguration" />
>>>
>>> John Baker
>>> --
>>> Web SSO
>>> IT Infrastructure
>>> Deutsche Bank London
>>>
>>> URL: http://websso.cto.gt.intranet.db.com
>>>
>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>
> ---
> Daniel Kulp
> dkulp@apache.org
> 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
dkulp@apache.org
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.
Re: Roles and permissions
Posted by Daniel Kulp <dk...@apache.org>.
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
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> Daniel Kulp <dk...@apache.org>
> 18/06/2008 14:43
> Please respond to
> users@cxf.apache.org
>
>
> To
> users@cxf.apache.org
> cc
>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
>
> On Jun 18, 2008, at 9:38 AM, Sergey Beryozkin wrote:
>
>> Hi,
>>
>> If so then I'd assuem it's something which needs to be fixed in a
>> jaxws asm processor, as this method
>>
>>>> Response getApplicationConfiguration(@PathParam("id") String id,
>>>> @Context SecurityContext sc);
>>
>> is unlikely to be part of whatever interface the JAX-WS endpoint
>> supports ?
>> Dan, what do you reckon ? Is it possible to push the methods to be
>> invoked over SOAP to a seperate interface so that the other methods
>> are not introspected on the implementation class itself ?
>
> Yes. The endpointInterface attribute on the WebService annotation
> would give us the interface that we would use.
>
> Alternatively, just add:
> @WebMethod(exclude = true)
> to the methods you don't want JAX-WS to look at.
>
> Dan
>
>
>
>>
>>
>> John, you can also try annotating a field instead
>>
>> @Context
>> private SecurityContext sc;
>>
>> Note it's not thread-safe but it will be fixed shorly
>>
>> Cheers, Sergey
>>
>>> Yes, I do.
>>>
>>> <!-- Define the REST service -->
>>> <jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
>>> address="/rest">
>>> <jaxrs:serviceBeans>
>>> <ref bean="service.beans.applicationConfiguration" />
>>> </jaxrs:serviceBeans>
>>> </jaxrs:server>
>>>
>>> <!-- Define the application configuration webservice -->
>>> <jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
>>> implementor="#service.beans.applicationConfiguration"
>>> address="/soap/applicationConfiguration" />
>>>
>>> John Baker
>>> --
>>> Web SSO
>>> IT Infrastructure
>>> Deutsche Bank London
>>>
>>> URL: http://websso.cto.gt.intranet.db.com
>>>
>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>
> ---
> Daniel Kulp
> dkulp@apache.org
> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
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?
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
Daniel Kulp <dk...@apache.org>
18/06/2008 14:43
Please respond to
users@cxf.apache.org
To
users@cxf.apache.org
cc
Subject
Re: Roles and permissions
On Jun 18, 2008, at 9:38 AM, Sergey Beryozkin wrote:
> Hi,
>
> If so then I'd assuem it's something which needs to be fixed in a
> jaxws asm processor, as this method
>
>>> Response getApplicationConfiguration(@PathParam("id") String id,
>>> @Context SecurityContext sc);
>
> is unlikely to be part of whatever interface the JAX-WS endpoint
> supports ?
> Dan, what do you reckon ? Is it possible to push the methods to be
> invoked over SOAP to a seperate interface so that the other methods
> are not introspected on the implementation class itself ?
Yes. The endpointInterface attribute on the WebService annotation
would give us the interface that we would use.
Alternatively, just add:
@WebMethod(exclude = true)
to the methods you don't want JAX-WS to look at.
Dan
>
>
> John, you can also try annotating a field instead
>
> @Context
> private SecurityContext sc;
>
> Note it's not thread-safe but it will be fixed shorly
>
> Cheers, Sergey
>
>> Yes, I do.
>>
>> <!-- Define the REST service -->
>> <jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
>> address="/rest">
>> <jaxrs:serviceBeans>
>> <ref bean="service.beans.applicationConfiguration" />
>> </jaxrs:serviceBeans>
>> </jaxrs:server>
>>
>> <!-- Define the application configuration webservice -->
>> <jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
>> implementor="#service.beans.applicationConfiguration"
>> address="/soap/applicationConfiguration" />
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
---
Daniel Kulp
dkulp@apache.org
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.
Re: Roles and permissions
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 18, 2008, at 9:38 AM, Sergey Beryozkin wrote:
> Hi,
>
> If so then I'd assuem it's something which needs to be fixed in a
> jaxws asm processor, as this method
>
>>> Response getApplicationConfiguration(@PathParam("id") String id,
>>> @Context SecurityContext sc);
>
> is unlikely to be part of whatever interface the JAX-WS endpoint
> supports ?
> Dan, what do you reckon ? Is it possible to push the methods to be
> invoked over SOAP to a seperate interface so that the other methods
> are not introspected on the implementation class itself ?
Yes. The endpointInterface attribute on the WebService annotation
would give us the interface that we would use.
Alternatively, just add:
@WebMethod(exclude = true)
to the methods you don't want JAX-WS to look at.
Dan
>
>
> John, you can also try annotating a field instead
>
> @Context
> private SecurityContext sc;
>
> Note it's not thread-safe but it will be fixed shorly
>
> Cheers, Sergey
>
>> Yes, I do.
>>
>> <!-- Define the REST service -->
>> <jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
>> address="/rest">
>> <jaxrs:serviceBeans>
>> <ref bean="service.beans.applicationConfiguration" />
>> </jaxrs:serviceBeans>
>> </jaxrs:server>
>>
>> <!-- Define the application configuration webservice -->
>> <jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
>> implementor="#service.beans.applicationConfiguration"
>> address="/soap/applicationConfiguration" />
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
If so then I'd assuem it's something which needs to be fixed in a jaxws asm processor, as this method
>> Response getApplicationConfiguration(@PathParam("id") String id,
>> @Context SecurityContext sc);
is unlikely to be part of whatever interface the JAX-WS endpoint supports ?
Dan, what do you reckon ? Is it possible to push the methods to be invoked over SOAP to a seperate interface so that the other
methods are not introspected on the implementation class itself ?
John, you can also try annotating a field instead
@Context
private SecurityContext sc;
Note it's not thread-safe but it will be fixed shorly
Cheers, Sergey
> Yes, I do.
>
> <!-- Define the REST service -->
> <jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
> address="/rest">
> <jaxrs:serviceBeans>
> <ref bean="service.beans.applicationConfiguration" />
> </jaxrs:serviceBeans>
> </jaxrs:server>
>
> <!-- Define the application configuration webservice -->
> <jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
> implementor="#service.beans.applicationConfiguration"
> address="/soap/applicationConfiguration" />
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Yes, I do.
<!-- Define the REST service -->
<jaxrs:server id="cxf.server.rest.ApplicationConfigurationService"
address="/rest">
<jaxrs:serviceBeans>
<ref bean="service.beans.applicationConfiguration" />
</jaxrs:serviceBeans>
</jaxrs:server>
<!-- Define the application configuration webservice -->
<jaxws:endpoint id="cxf.server.soap.ApplicationConfigurationService"
implementor="#service.beans.applicationConfiguration"
address="/soap/applicationConfiguration" />
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
18/06/2008 12:04
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
<us...@cxf.apache.org>
Subject
Re: Roles and permissions
Hi
I'm confused by this stacktrace
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
> counts of IllegalAnnotationExceptions
> javax.ws.rs.core.SecurityContext is an interface, and JAXB can't handle
> interfaces.
> this problem is related to the following location:
> at javax.ws.rs.core.SecurityContext
> at private javax.ws.rs.core.SecurityContext
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
CXF JAX-RS does not do any asm processing at the moment. I'm wondering, do
you have a combined
JAX-WS/JAX-RS service and perhaps the cxf jaxws asm handler attempts to
preprocess this method as well ?
Cheers, Sergey
> So it doesn't work or I'm doing it wrong:
>
> @GET
> @Path("/get/{id}/")
> @ProduceMime("application/xml")
> Response getApplicationConfiguration(@PathParam("id") String id,
> @Context SecurityContext sc);
>
> Any other thoughts?
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <se...@iona.com>
> 18/06/2008 10:37
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
> <us...@cxf.apache.org>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> I'm sorry, it's a lack of the docs...
>
> Please use the SecurityContext from a jaxrs package
> javax.ws.rs.core
> Hope it will work
>
> Cheers, Sergey
>
> ----- Original Message -----
> From: "John-M Baker" <jo...@db.com>
> To: <us...@cxf.apache.org>
> Cc: <us...@cxf.apache.org>
> Sent: Wednesday, June 18, 2008 10:13 AM
> Subject: Re: Roles and permissions
>
>
>> Sergey,
>>
>> Using @Context SecurityContext sc didn't work:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
>> handle interfaces.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>> org.apache.cxf.security.SecurityContext does not have a no-arg default
>> constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> And the SecurityContextImpl didn't work either:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a
no-arg
>> default constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.jaxrs.provider.SecurityContextImpl
>> at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
>>
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> Any thoughts?
>>
>>
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>>
>>
>> "Sergey Beryozkin" <se...@iona.com>
>> 17/06/2008 16:04
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> <us...@cxf.apache.org>
>> cc
>>
>> Subject
>> Re: Roles and permissions
>>
>>
>>
>>
>>
>>
>> Hi John
>>
>> Try
>>
>> @Context SecurityContext sc
>>
>> as a parameter in your method
>>
>> and then sc.isUsertInRole()...
>>
>> The other option is to experiment with Acegi (Spring Security), as far
> as
>> applying permissions to individual methods - I haven't
>> tried myself. I think JAX-RS will support some explicit EE security
>> annotations too at some time
>>
>> Cheers, Sergey
>>
>>
>>> Hello,
>>>
>>> Is there any way to use annotations to apply roles to methods in a
>>> Webservice or REST call? I'd like to be able to configure an
>> application
>>> to let users within one group access a set of methods that another set
>> of
>>> users can not access.
>>>
>>> Is there a way to get the HttpRequest object from a method?
>>>
>>> Thanks,
>>>
>>>
>>> John Baker
>>> --
>>> Web SSO
>>> IT Infrastructure
>>> Deutsche Bank London
>>>
>>> URL: http://websso.cto.gt.intranet.db.com
>>>
>>>
>>> ---
>>>
>>> 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.
----------------------------
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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I'm confused by this stacktrace
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
> counts of IllegalAnnotationExceptions
> javax.ws.rs.core.SecurityContext is an interface, and JAXB can't handle
> interfaces.
> this problem is related to the following location:
> at javax.ws.rs.core.SecurityContext
> at private javax.ws.rs.core.SecurityContext
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
CXF JAX-RS does not do any asm processing at the moment. I'm wondering, do you have a combined
JAX-WS/JAX-RS service and perhaps the cxf jaxws asm handler attempts to preprocess this method as well ?
Cheers, Sergey
> So it doesn't work or I'm doing it wrong:
>
> @GET
> @Path("/get/{id}/")
> @ProduceMime("application/xml")
> Response getApplicationConfiguration(@PathParam("id") String id,
> @Context SecurityContext sc);
>
> Any other thoughts?
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <se...@iona.com>
> 18/06/2008 10:37
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
> <us...@cxf.apache.org>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> I'm sorry, it's a lack of the docs...
>
> Please use the SecurityContext from a jaxrs package
> javax.ws.rs.core
> Hope it will work
>
> Cheers, Sergey
>
> ----- Original Message -----
> From: "John-M Baker" <jo...@db.com>
> To: <us...@cxf.apache.org>
> Cc: <us...@cxf.apache.org>
> Sent: Wednesday, June 18, 2008 10:13 AM
> Subject: Re: Roles and permissions
>
>
>> Sergey,
>>
>> Using @Context SecurityContext sc didn't work:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
>> handle interfaces.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>> org.apache.cxf.security.SecurityContext does not have a no-arg default
>> constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.security.SecurityContext
>> at private org.apache.cxf.security.SecurityContext
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> And the SecurityContextImpl didn't work either:
>>
>> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
>> counts of IllegalAnnotationExceptions
>> org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a no-arg
>> default constructor.
>> this problem is related to the following location:
>> at org.apache.cxf.jaxrs.provider.SecurityContextImpl
>> at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
>>
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
>> at
>> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>>
>> Any thoughts?
>>
>>
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>>
>>
>> "Sergey Beryozkin" <se...@iona.com>
>> 17/06/2008 16:04
>> Please respond to
>> users@cxf.apache.org
>>
>>
>> To
>> <us...@cxf.apache.org>
>> cc
>>
>> Subject
>> Re: Roles and permissions
>>
>>
>>
>>
>>
>>
>> Hi John
>>
>> Try
>>
>> @Context SecurityContext sc
>>
>> as a parameter in your method
>>
>> and then sc.isUsertInRole()...
>>
>> The other option is to experiment with Acegi (Spring Security), as far
> as
>> applying permissions to individual methods - I haven't
>> tried myself. I think JAX-RS will support some explicit EE security
>> annotations too at some time
>>
>> Cheers, Sergey
>>
>>
>>> Hello,
>>>
>>> Is there any way to use annotations to apply roles to methods in a
>>> Webservice or REST call? I'd like to be able to configure an
>> application
>>> to let users within one group access a set of methods that another set
>> of
>>> users can not access.
>>>
>>> Is there a way to get the HttpRequest object from a method?
>>>
>>> Thanks,
>>>
>>>
>>> John Baker
>>> --
>>> Web SSO
>>> IT Infrastructure
>>> Deutsche Bank London
>>>
>>> URL: http://websso.cto.gt.intranet.db.com
>>>
>>>
>>> ---
>>>
>>> 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.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
counts of IllegalAnnotationExceptions
javax.ws.rs.core.SecurityContext is an interface, and JAXB can't handle
interfaces.
this problem is related to the following location:
at javax.ws.rs.core.SecurityContext
at private javax.ws.rs.core.SecurityContext
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
at
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
So it doesn't work or I'm doing it wrong:
@GET
@Path("/get/{id}/")
@ProduceMime("application/xml")
Response getApplicationConfiguration(@PathParam("id") String id,
@Context SecurityContext sc);
Any other thoughts?
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
18/06/2008 10:37
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
<us...@cxf.apache.org>
Subject
Re: Roles and permissions
I'm sorry, it's a lack of the docs...
Please use the SecurityContext from a jaxrs package
javax.ws.rs.core
Hope it will work
Cheers, Sergey
----- Original Message -----
From: "John-M Baker" <jo...@db.com>
To: <us...@cxf.apache.org>
Cc: <us...@cxf.apache.org>
Sent: Wednesday, June 18, 2008 10:13 AM
Subject: Re: Roles and permissions
> Sergey,
>
> Using @Context SecurityContext sc didn't work:
>
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
> counts of IllegalAnnotationExceptions
> org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
> handle interfaces.
> this problem is related to the following location:
> at org.apache.cxf.security.SecurityContext
> at private org.apache.cxf.security.SecurityContext
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
> org.apache.cxf.security.SecurityContext does not have a no-arg default
> constructor.
> this problem is related to the following location:
> at org.apache.cxf.security.SecurityContext
> at private org.apache.cxf.security.SecurityContext
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
> And the SecurityContextImpl didn't work either:
>
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
> counts of IllegalAnnotationExceptions
> org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a no-arg
> default constructor.
> this problem is related to the following location:
> at org.apache.cxf.jaxrs.provider.SecurityContextImpl
> at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
>
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
> Any thoughts?
>
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <se...@iona.com>
> 17/06/2008 16:04
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> Hi John
>
> Try
>
> @Context SecurityContext sc
>
> as a parameter in your method
>
> and then sc.isUsertInRole()...
>
> The other option is to experiment with Acegi (Spring Security), as far
as
> applying permissions to individual methods - I haven't
> tried myself. I think JAX-RS will support some explicit EE security
> annotations too at some time
>
> Cheers, Sergey
>
>
>> Hello,
>>
>> Is there any way to use annotations to apply roles to methods in a
>> Webservice or REST call? I'd like to be able to configure an
> application
>> to let users within one group access a set of methods that another set
> of
>> users can not access.
>>
>> Is there a way to get the HttpRequest object from a method?
>>
>> Thanks,
>>
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>> ---
>>
>> 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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
I'm sorry, it's a lack of the docs...
Please use the SecurityContext from a jaxrs package
javax.ws.rs.core
Hope it will work
Cheers, Sergey
----- Original Message -----
From: "John-M Baker" <jo...@db.com>
To: <us...@cxf.apache.org>
Cc: <us...@cxf.apache.org>
Sent: Wednesday, June 18, 2008 10:13 AM
Subject: Re: Roles and permissions
> Sergey,
>
> Using @Context SecurityContext sc didn't work:
>
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
> counts of IllegalAnnotationExceptions
> org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
> handle interfaces.
> this problem is related to the following location:
> at org.apache.cxf.security.SecurityContext
> at private org.apache.cxf.security.SecurityContext
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
> org.apache.cxf.security.SecurityContext does not have a no-arg default
> constructor.
> this problem is related to the following location:
> at org.apache.cxf.security.SecurityContext
> at private org.apache.cxf.security.SecurityContext
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
> And the SecurityContextImpl didn't work either:
>
> Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
> counts of IllegalAnnotationExceptions
> org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a no-arg
> default constructor.
> this problem is related to the following location:
> at org.apache.cxf.jaxrs.provider.SecurityContextImpl
> at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
> at
> com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
>
> Any thoughts?
>
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
>
>
> "Sergey Beryozkin" <se...@iona.com>
> 17/06/2008 16:04
> Please respond to
> users@cxf.apache.org
>
>
> To
> <us...@cxf.apache.org>
> cc
>
> Subject
> Re: Roles and permissions
>
>
>
>
>
>
> Hi John
>
> Try
>
> @Context SecurityContext sc
>
> as a parameter in your method
>
> and then sc.isUsertInRole()...
>
> The other option is to experiment with Acegi (Spring Security), as far as
> applying permissions to individual methods - I haven't
> tried myself. I think JAX-RS will support some explicit EE security
> annotations too at some time
>
> Cheers, Sergey
>
>
>> Hello,
>>
>> Is there any way to use annotations to apply roles to methods in a
>> Webservice or REST call? I'd like to be able to configure an
> application
>> to let users within one group access a set of methods that another set
> of
>> users can not access.
>>
>> Is there a way to get the HttpRequest object from a method?
>>
>> Thanks,
>>
>>
>> John Baker
>> --
>> Web SSO
>> IT Infrastructure
>> Deutsche Bank London
>>
>> URL: http://websso.cto.gt.intranet.db.com
>>
>>
>> ---
>>
>> 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
Re: Roles and permissions
Posted by John-M Baker <jo...@db.com>.
Sergey,
Using @Context SecurityContext sc didn't work:
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
counts of IllegalAnnotationExceptions
org.apache.cxf.security.SecurityContext is an interface, and JAXB can't
handle interfaces.
this problem is related to the following location:
at org.apache.cxf.security.SecurityContext
at private org.apache.cxf.security.SecurityContext
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
at
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
org.apache.cxf.security.SecurityContext does not have a no-arg default
constructor.
this problem is related to the following location:
at org.apache.cxf.security.SecurityContext
at private org.apache.cxf.security.SecurityContext
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
at
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
And the SecurityContextImpl didn't work either:
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1
counts of IllegalAnnotationExceptions
org.apache.cxf.jaxrs.provider.SecurityContextImpl does not have a no-arg
default constructor.
this problem is related to the following location:
at org.apache.cxf.jaxrs.provider.SecurityContextImpl
at private org.apache.cxf.jaxrs.provider.SecurityContextImpl
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration.arg1
at
com.db.websso.integration.services.jaxws_asm.GetApplicationConfiguration
Any thoughts?
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
"Sergey Beryozkin" <se...@iona.com>
17/06/2008 16:04
Please respond to
users@cxf.apache.org
To
<us...@cxf.apache.org>
cc
Subject
Re: Roles and permissions
Hi John
Try
@Context SecurityContext sc
as a parameter in your method
and then sc.isUsertInRole()...
The other option is to experiment with Acegi (Spring Security), as far as
applying permissions to individual methods - I haven't
tried myself. I think JAX-RS will support some explicit EE security
annotations too at some time
Cheers, Sergey
> Hello,
>
> Is there any way to use annotations to apply roles to methods in a
> Webservice or REST call? I'd like to be able to configure an
application
> to let users within one group access a set of methods that another set
of
> users can not access.
>
> Is there a way to get the HttpRequest object from a method?
>
> Thanks,
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
> ---
>
> 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.
Re: Roles and permissions
Posted by Sergey Beryozkin <se...@iona.com>.
Hi John
Try
@Context SecurityContext sc
as a parameter in your method
and then sc.isUsertInRole()...
The other option is to experiment with Acegi (Spring Security), as far as applying permissions to individual methods - I haven't
tried myself. I think JAX-RS will support some explicit EE security annotations too at some time
Cheers, Sergey
> Hello,
>
> Is there any way to use annotations to apply roles to methods in a
> Webservice or REST call? I'd like to be able to configure an application
> to let users within one group access a set of methods that another set of
> users can not access.
>
> Is there a way to get the HttpRequest object from a method?
>
> Thanks,
>
>
> John Baker
> --
> Web SSO
> IT Infrastructure
> Deutsche Bank London
>
> URL: http://websso.cto.gt.intranet.db.com
>
>
> ---
>
> 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