Re: Design problem : security layers
Wojtek wrote:
Your JSP pages access the database? Or even know about it?
subtenante wrote:
Well no, i thought it was obvious. The database interface is done in a
separate package.
So your JSPs do not use the database classes.
(BTW, JSPs aren't usually thought of as being in a package.)
That's my point. I want the jsp from the frontend to use the frontend
package, containing only lightweight versions of the objects. This
way, i am sure it is impossible to update anything not permitted from
the jsp. Only a very few setters are available, and not even all of
the getters.
You enforce security by how you access an object, not by needless duplication
of the object.
But in the backend of the website, i need the jsp's to use the backend
package, containing the objects, inheriting from the frontend ones,
and having the additional features to make changes to the DB.
JSPs are a strictly front-end artifact. JSPs "in the backend [sic]" are a
contradiction in terms. JSPs are for visual presentation (or the equivalent),
the very definition of "front end".
This way i am sure that when a new feature is added to a jsp page, it
can not be problematic for security : from the design level it is not
permitted to add features to update not permitted information.
This is better done without duplicating your classes.
By the way, the frontend package uses a very limited DB account, only
granted with "execute". For the backend I have a lot of DB accounts,
each with the necessary rights and no more.
You really only need one DB account for the whole DB layer, and the front end
would never access it.
The way I have layered the classes, I can switch database technologies
by simply re-writing ONE set of classes in the "backend", and setting a
configuration file. Whether that new database is a different database,
an XML file, a flat file, or whatever, it is completely hidden from the
JSP.
Easily said, but i guess you would have to browse all your classes to
make the appropriate changes in the request they do to the DB anyways.
I think it doesn't minimize the number of lines to change, only the
place where you store them.
Am i wrong ?
Yes, you are.
The truth is exactly the opposite. You don't "browse all your classes to make
the appropriate changes", you open the source for the one and only one class
that needs a change. The number of lines to change is approximately half of
the scheme that you propose.
Yes but i have two sets of jsp's. One in the frontend, that must use
limited versions of the Objects (therefore i give no way to put a mess
in my data this way, everything is strictly controlled). One in the
backend, where i am slightly more relax (slightly).
JSPs are front-end artifacts. Only.
What do you mean by a "set of jsp's [sic] ... in the backend [sic]"?
The phrase makes no sense to me whatsoever. Why would you want HTML in the
back end, where no one can see it?
Yes but i don't trust the next developpers/maintainers. I have seen
ugly things, precisely that's the reason i am doing everything from
scratch. I want a design that makes completely sure that the people
that will care about this later will understand which data is
sensitive and which is not, so that they don't do ugly things.
This can be accomplished without making maintainers' jobs more difficult, too.
I strongly recommend that you study Wojtek's suggestions in depth. They are
sound and will accomplish the goals of isolation and security that you
espouse, with a sturdier and more compact architecture.
--
Lew