Hi Craig,
"Craig R. McClanahan" wrote:
>
> Daniel Lopez wrote:
>
> > I understand, I'm not saying it cannot be done with isUserInRole(). But in my
>architecture I don't
> > need to use isUserInRole() inside my business logic because the "security
>framework" already
> > performed the appropriate security checks. So my perform() method just does that:
>perform the
> > operation. I'm just trying to say that I find it much better when all the checks
>are performed in
> > the security framework and the business logic just performs business logic. IMHO,
>the security
> > framework of the JSDK2.2 is not able to do that because it forces you to specify
>the security policy
> > (role/permissions requiered to perform an operation) STATICALLY.
> >
>
> I understand your point (about not wanting to use isUserInRole() in your business
>logic), even if I
> don't agree with you :-). Now, the question becomes, *how* would you propose to
>specify and implement
> a security policy, in a general specification, that does what you suggest? It's all
>well and good to
> say that something should be standardized, but it's much more useful to consider
>some example
> approaches and see if they are generally applicable or not.
Well, I already implemented this approach and it's working fine for me,
I agree with you that it's all well and good to say something should be
done, but it's more useful to have an example, and that's why I first
try things before claiming them. That's why I do:
.- In my framework, I define an interface/abstract class called
SecurityModel which has the necessary methods to get the information
from the security model you want to represent. That means the different
Principals, Roles and Permissions in the system and their relathionship.
These methods are called when the web application is initialized so this
information is generated dynamically and as it's got through an
interface, it can be generated from a database, an XML file, an RMI
proxy... The class that implements the interface is specified in the web
application descriptor(wad) and is loaded in runtime. That solves the
question of defining a domain for every user in the database and that
changes in the database are reflected in the security specification.
.- As the second element, I defined another interface/abstract class
called SecurityPolicy which is in charge of: given a ServletRequest,
return the Role and the Permission required to perform the action
associated with this request. You then specify a class that implements
this interface, also in the wad, that is loaded in runtime and that is
requested every time a request is performed to get the information
necessary to execute the action asssociated to the request. In order to
avoid a big if/else inside this class, you can optionally specify this
information in the action class itself(by implementing an interface) so
it's much clearer which permissions are requiered for every action.
Lastly and useful when you are in the test phase, you can also specify
this information(some or all of it) statically in the wad file so you
don't have to recompile anything to change some permissions.
> > PD: On a side note, this is not an attack of any kind to the guys that produced
>the specification
> > ;). On the contrary, they have been quite open minded and interested in feedbak.
>But they told me
> > they haven't got much feedback from this issue, which I find quite interesting, so
>that's why I'm
> > trying to generate some. I think it's better to discuss things in advance and do
>it almost right
> > from the beginning, than getting a final specification and start complaining
>because it could have
> > done better.
>
> I agree here ... let's continue to explore what might be possible by working through
>a couple of same
> approaches to your proposed scenario:
>
> * Same business logic is executed by multiple users.
.- The security policy returns the required Role/Permission based on the
call to the business logic you are trying to call. Every user should
have been granted this Role/Permission at init time by the security
model.
So a call to "http://.../checkBalance.go" would make the security policy
return the Role "Administration", Permission "Read", if your user has
been assigned these by the security model, the action class, which
consists just in business logic, is allowed to be performed. You could
also implement the security policy inside the action class itself, but
this is optional and is separated in two different methods.
> * Different users get to do different "things" based
> on their assigned roles within that business logic.
.- A call to "http://.../UpdateUserData.go?userName=Z&fullName=..." At
init time, a role "UserX" is created for every user X in the database
and every user is granted his own role with all permissions, the
managers are given all the roles to modify all the users. Then, at
request time, the security policy would read the parameter userName=X
and would then return Role="UserX" , permission "Modify". The framework
would then enforce that the authenticated user has this requiered
Role/Permission and access would then be granted/denied depending on
this information.
> * Security framework identifies and enforces this
> "from the outside" -- i.e. no conditional calls within
> the business logic to determine roles.
I guess the above examples make it clearer. At init time the security
model defines "the players", at request time the security policy defines
"the rules", the framework(referee) enforces the rules based on the
information provided for both elements. Both elements are defined as
interfaces so the information can be taken from anywhere and it makes
them container independent. So my proposal was on the way of
specifying(standardizing) this interfaces, instead of/in addition to the
XML specication, so all the containers have to use this way of getting
the information. Then every container could play their own tricks with
their implementation(faster user cache, providing already implemented
solutions...) as long as they were interface-compatible. Applications
would then be fully transportable = no security redefinition per
container = users would be happy; vendors would have ground to play
their tricks = earning their bucks = vendors would be happy. What a
happy family! ;) I know, I know, it wouldn't be such a perfect world but
we spaniards do have a weird sense of humour :), or I do :)).
> At the moment, I'm not seeing clearly how you would do these things in a general way.
> Craig
I hope this helps in that regard. On a side note, I would still keep the
isUserInRole() method because, as you mentioned, it could be useful
building the interface and even in some extreme cases in the business
logic(if you find your security policy would get too complicate). But
it's use in the business logic should be optional, which is not the case
with the current specification.
As I mentioned above, I already have an implementation working of such a
framework and even though I won't say I have tested it with a zillion
users, it has worked pretty well with all the applications I have done
so far. No security logic intermixed with business logic at all. But I
wanted to discuss this because I wanted to see if somebody can find a
terminal flaw in this design. Otherwise, I'd want to share this idea and
if it gets into the specification and vendors implement such a framework
for me.... perfect!
And thanks Craig, even though we don't always agree, I always learn from
such discussions with you :).
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
