One technique I used was to include a system profile in the data layer that allows the business layer to retrieve an
informationfor a user account such as what is the user allowed to see and do. This way, none of the security related
informationis stored at the user layer. You can certainly employ encryption of various kinds to ensure that it isn't
evenvisible during transmission between user and business layers.
The profile, being the basis for the data driven security management, can be constructed at the time the user account
iscreated. It can be modified by an administrator to increase or decrease exposure to other modules / data in the app /
db.All of the authentication happens, then, between the business layer and the data layer so that no account
informationcan ever be retreived outside the server farm environment.
Just some thoughts.
Tamir
> -----Original Message-----
> From: Bruno Wolff III [mailto:bruno@wolff.to]
> Sent: Thursday, April 03, 2003 3:41 PM
> To: Tamir Halperin
> Cc: Peter Csaba; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Rules, Triggers something more challenging
>
>
> On Thu, Apr 03, 2003 at 12:52:10 -0500,
> Tamir Halperin <tamir@brobus.net> wrote:
> > I'd like to make a suggestion, Peter:
> >
> > You may very well find a way to contstrain inserts using
> pgsql according to your business rules, but I observe that
> you're beginning to develop a dependency on the data layer
> for your business logic.
> >
> > The reason you may not want to rely on db componentry
> (rules, triggers, etc...) to implement this type of business
> logic is because at some point in the future your business
> logic may change and then you're required to heavily modify
> your database when it may not be a problem with the data.
>
> On the other hand implementing security in the application
> doesn't work
> if the application runs on the user's machine. For example
> Peoplesoft's
> security for version 7.x is totally broken if you let people run two
> tier (which you have to to let people do some things). The
> app eventually
> connects to the data base with full update access to all
> tables and relies
> on the user not tampering with the app.
>
> If the app runs on a secure machine then implementing security on the
> app server is reasonable (at least under some circumstances).
>
