Identifying a user in the database

Discussions

EJB design: Identifying a user in the database

  1. Identifying a user in the database (2 messages)

    Hi !
    New to this but here is the scenario :

    In our database (Informix) we use SQLROLE to minimize the exposion of tables and the possibilitys to access/change data to the user, we do a "SET ROLE therole" from the applications depending on what application hi/she is using.

    We also do a lot of logging with stored procedures and triggers in the database to be able to track who did what when.

    When moving to J2EE env. I understand that the appserver are holding a pool of connections to the database all connected as some kind of "appserveruser".

    Question :
    A) How do I find out what user is actually trying to access the database ?

    Or do I have to "move" my security issues from the ROLE concept in the database to the prinicple concept of the J2EE spec and also lose the possiblily to logg activitys at the DB level ?

    TIA
    Jan Nilsson
  2. Hi,

    From what I understand, I think you can solve the problem by passing J2EE principal name as input parameter while calling any stored procedure in your informix backend.

    <quote>
    Or do I have to "move" my security issues from the ROLE concept in the database to the prinicple concept of the J2EE spec and also lose the possiblily to logg activitys at the DB level ?
    </quote>

    Frankly speaking, I do not quite understand what you meant here. Although, would like to add one thing here that you will have to do principal mapping between app server and database server as both of them possibly belong to separate security domains (as far as I know, from your post). Meaning you do not have to get rid of Roles from your backend at the same time you can stick to J2EE principals as well. However, at some point of time, you have to map these J2EE principal users to users that correspond to roles in your backend.

    Hope this helps,
    Reema.
  3. Reema
    Thx for the answer.

    The logging is activated by a trigger so the application is not aware of the logging technics, the trigger calls the stored procedure and the trigger fires on update, delete and insert statements.
    If we should "move" that starting mechanism from the DB's triggers uppwards to the application (server) that is what I mean by <"move" my security issues>.