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