Hi Marc,
a nice example, I wasn't even aware of the @SecurityContext... :)
For our api I decided not to use container based security, to have more
control. One requirement for us is that we can authorize applications
(permanent permissions for applications) and the user can grant
permissions to some application (temporary permissions).
Today I wrote some security handling class for this - guess what it's
named - SecurityContext :) - that is put into my base resource class
(hinding it to subresources), resources then can express what security
requirements they have. Obviously, not as nice as annotations :)
Thanx && cheers,
Martin
On Fri, 2008-03-07 at 16:21 -0500, Marc Hadley wrote:
> Not exactly what you describe but perhaps the following will help:
>
> http://weblogs.java.net/blog/mhadley/archive/2008/03/authentication.html
>
> In the future we'll support the JSR 250 annotations like @RolesAllowed
> on resource classes but for now use of SecurityContext and web.xml
> constraints will work.
>
> Marc.
>
> On Mar 6, 2008, at 12:11 PM, Martin Grotzke wrote:
>
> > Hi,
> >
> > I want to add some authentication handling to our api and think about
> > possible solutions.
> >
> > I would like to do this with annotations, e.g. some @Security
> > annotation, that might have attributes like "forceSSL",
> > "requireAppPermissions", "authMode" etc.
> >
> > Then all resources would have to be proxied, so that the security
> > requirements can be checked/handled. And proxying resources of course
> > also means proxying subresources.
> >
> > I see the following possible solutions for doing this:
> > 1) use the IoC container to obtain some proxied instance; for
> > subresources, population of properties (like the actual user or
> > userId) would be done by the resource afterwards
> > 2) use some custom (application specific) factory that knows about
> > resources and is given all required properties for creation of some
> > resource, and that then add proxying "manually"...
> > 3) use the jersey ComponentProvider as described in Pauls posting
> > ([1]),
> > that can provide also integration of some IoC container.
> >
> > I most like door 3), as it provides the best integration.
> > 1) does not allow constuctor-based injection or bean validation (like
> > springs afterPropertiesSet). 2) is also somehow too much homegrow...
> >
> > What do you think? Would it be an option to provide s.th. like
> > solution
> > 3), could I help somehow to achieve this?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > [1] https://jersey.dev.java.net/servlets/ReadMsg?listName=users&msgNo=644
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>