• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Database Authentication?

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am working on a product that requires authentication of users right down to the Database tier, because we have a requirement that direct database access (outside of the application) is still secure. This is possible in Oracle using VPD policies driven via database user accounts, however this is a major limitation to scalability (prevents "normal" database connection pooling) and prevents integration with LDAP servers etc.

The J2EE Security approach has always been that security terminates at the edge of the J2EE container. Is there a standard (i.e. Application Server independent) approach to using container-based security and passing a user's identity on to the database tier? What are the best practices in this area?

Thanks,

Chris Nappin.
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris,
We have a similiar requirement on my current project. If you are using Oracle, you can take a round-about approach to circumvent the connection pool limitation and enforce row-level security. What we do is upon authentication, we take the Principal name and add it (with other adt) to a seperate user table. When a request comes to the back end, we set the user context in the connection from the pool and then a stored procedure in Oracle filters the rows returned based on the data in the user table. It is a little outside-the-box, but works well and makes the developers happy since they do not have to construct their own SQL clauses to enforce access control.
 
Chris Nappin
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Chris,

I assume by "stored procedure" you mean VPD policy?

How do you prevent users from logging into the database directly and manually setting an arbitrary context themselves?

Is there no vendor-independent way of doing this? Is any of this covered by your book please?

Thanks,

Chris.
 
Author
Posts: 159
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Nappin:
Hi Chris,

I assume by "stored procedure" you mean VPD policy?

How do you prevent users from logging into the database directly and manually setting an arbitrary context themselves?

Is there no vendor-independent way of doing this? Is any of this covered by your book please?

Thanks,

Chris.




Chris,

This is a common security question during JDBC spec review meetings...:-) Unfortunately there is no vendor-neutral way to represent security in JDBC...and downunder.

In our book, we do cover all possible security options in JDBC (Of course..the common mechanisms found in DB providers). In our book we discuss With JDBC 3.0 characteristics, JDBC establishes compatibility with J2EE Conenctor Architecture...which gives a lot features about using Security and Single Sign-on.
 
Hold that thought. Tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic