RE: [Springframework-developer] polishing and new features - security model??????

[Alef A. \(JTeam\) <al...@jt...>]

<quote>
 C - [ depends on project ]
 B - POJO Business Objects
 A - POJO DAO Objects (Hibernate in my case)
 
 Objects in each layer may only call other Object in the same layer or 
 Objects in the NEXT lower layer. 
 
 Given I was to build an EJB solution, layer C would be a SINGLE session

 facade SLSB (single because I want to avoid COSTLY inter EJB calls). 
 For testing/QA, I would write unittests at layer C to test B and A, and

 maybe unittests at layer D to test the SLSB. For maintenance 
 (developers only) I could write another POJO java-app running at C. If 
 I wanted to CHANGE the solution-type from EJB to webinterface I could 
 either replace the SLSB at C with servlets/jsps/etc. or write a 
 servlet/jsp/etc. layer at D using EJB layer C.
</quote>
Well, this isn't very odd! It resembles the way we (and probably a lot
Of other people) do things...

<quote>
 The above appears VERY FLEXBILE to me. If I got you right, you would 
 like to add security at layer A. This would screw up the model at 
 various points (my problem - I do not have to use those security 
 features). Furthermore, it might not be a good idea to have a depency 
 in a Spring security API on SPECIFIC other security providing 
 frameworks such as EJB and Servlets - relying on the Principal 
 interface sort of introduces such a dependency, though.
 
 Please don't get me wrong: These are mainly my thoughts on how your 
 proposal would affect my current model... 
</quote>
I totally get your point. The way you're working is exactly the same as
We do. We call layers A & B (they don't differ much here) the module
layer here, the layer above is the component layer containing business
logic... Modules can't have security, can't have io, can't have
networking etctera (basically all EJB forbids)... The component layer
contains transactions/security, etctera.

The thing is, that the security model J2EE provides does not meet our
demands when it comes to security for __parts of objects__. I'm trying
to figure out something to add this. This does not mean I'm intruding on
the module level (A+B). You can compare it a lot with the validation
framework. We're having the commons validator included as validator for
the Spring framework (just extend the validator interface and use the
commons validator there). Each data object in our system has a
validation.xml file (located right beside the class file, called
[class].validation.xml). This means I haven't intruded on the data
level, just added a descirptorfile, describing validation rules... No
extra interface (I hate that ;-). Same thing holds for the Hibernate
stuff... We're using a proprietary little farmework for integration of
Hibernate into Spring (would rather have used Spring here, but the
framework is already in place for a long time). The Hibernate files are
placed right besides the data files and are called [class].hbm.xml.

Right now I want to add security. HOW the security is done, is actually
determine by the security-implementation (in this cause a
RoleObjectPermissionsWhatever, __located at the component level (Spring
+ C)__, however using the descriptor files from the module level
(A+B)... No extra interface or classes to extend, just an extra
description.

What the criteria for the permissions would be, is totally up to the
implementation. In this case I need Role/Principal information, which
means I either need the SessionContext/EntityContext or a ServletRequest
(whatever, something using JAAS/javax.security). This means the
implementation can __never__ be located at the modulelayer (A+B). Other
implementations would provide time based permissions (between 2am-3am
not possible to edit backup schedule, because backup is actually done
then)...

Anyway, I hope this clarifies things a little bit and I hope to get some
more feedback and stuff (people just shouting __arghh this is ugly__
would do as well!!!)...

Thanx,

Alef