Hi Alex,
AFAIK, the only things you have when using JSDK specified security are
those you mention: Defining roles in web.xml and using isUserInRole()
inside your code. We thought it could have done better and we pointed
out the shortcomings, like your second option, to the spec guys. They
answered that that was right, but as pretty much nobody was complaining
about it, they assumed it was a feature that was not required. So we
ended up implementing our own security architecture that handles this
kind of things nicely.
Our system allows you to specify the security requirements per-request,
so you can specify a different domain depending on the parameters (like
which object the operation is going to be performed upon) and the
environment (like which user is authenticated). These settings are
specified through interfaces and abstract classes, so it wouldn't be too
hard to create a specificacion using them. There are some other
shortcomings that forced us to implement our own solution, but I won't
get into detail.
Sorry about the long answer, the short one that I was told by the spec
guys was "no, that's everything that you have".
regards,
D
Alex Paransky wrote:
>
> We are in a process of developing an application, and are looking for ways
> to implement security, we have the following requirements:
>
> 1. There are operations that certain members cannot perform in general
> 2. There are operations that certain members cannot perform relative to an
> object (owner vs non-owner)
>
> What are some of the mechanims that you are using to deal with these
> problems. I assume, in the first case you can use deployment descriptor.
> Also isInRole query can be made to determine if particular option should be
> shown to the user during the .JSP processing.
>
> The second option is a bit more difficult to implement, since a particular
> user can be an owner of some objects but not others. How can this
> requirement be implemented?
>
> Thanks.
> -AP_
