• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Where to implement data security

 
David Frahm
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a web application that needs some programmatic security added to keep some users from seeing some of the data.

What I have to do is add some SQL to almost all statements that calls a db function we wrote, passing in some parms like userid, record key, and user role.

My question is where is the most appropriate place to have this security? I have a couple ideas:

1.) Create a new method in the Struts BaseAction and call it from the actual actions performAction(). If it doesn't pass then forward to a new page with appropriate message.

2.) Create a new SecureDAO class, based on our existing PreparedDAO class (typical class for PreparedStatements). In SecureDAO, create a method that would return the SQL for checking security. Then each implementing DAO would call that method to get the extra SQL, set/bind the necessary PreparedStatement parms in it.

Basically #1 would issue it as a separate query, prior to getting any data for the page, and #2 would add it in with the query for the page.

I am asking for comments because I want to implement this in the most secure way. I want to leverage as much OO as possible so that it is hard for developers to not do the proper security checking. I need to be able to report to mgmt that the data is secure with 100% confidence.

Any help would be appreciated!

More Info:
Per the DBA's, the security is very complex and the db is very large therefore it is not feasable to implement RDBMS row-level security for all our needs. It would be too slow, etc.

This is running on WebSphere v5 and Oracle 8i and 9i.

Thanks!
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Per the DBA's, the security is very complex and the db is very large therefore it is not feasable to implement RDBMS row-level security for all our needs. It would be too slow, etc

I can only presume you need security like because your data model contains data for a range of different orgazations in the same tables, right? That's the usual case for row level security. Well if that's the case, your DBA is being negligent telling you to implement security in your application, rather than in the schema, because its presuming that your application is the only client app which will ever connect to the dabatase. Also row level security works kind of like you are doing it anyway - with a bit of PL\SQL per table to handle security. If you want to secure parts of the model then thats really where the security should be defined - in the model.

That aside, since this is DB autherisation, rather than application authentication I reckon your idea of implementing it in your DAO layer sounds good.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic