Re: Connect to Oracle from J2EE. Use Oracle connection pooling or Java

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:<uhj781oocbe3a2_at_corp.supernews.com>...
> "John Ryan" <john.ryan_at_denovopharma.com> wrote in message
> news:1320e374.0206260135.78f47dcf_at_posting.google.com...
> > DBAs,
> >
> > The argument is - from a Java Application Server (using J2EE) should
> > you:-
> >
> > (a) Let J2EE manage the database connection pooling (and therefore
> > connect to a single Oracle USER) or
> >
> > (b) Let Oracle 8i manage the connection pooling (9i soon), with every
> > user connecting to a dedicated NAMED Oracle USER and therefore tighten
> > security
> >
> > I think the Java Development Architect is suffering from "not invented
> > in Java" syndrome here. He's insisting that the team NEED to connect
> > to Oracle through a single USERID and therefore handle all the
> > security within the Java Application Server and the custom built
> > application itself. His argument INCLUDES the need to pool (ie.
> > multiplex) database connections in the Java Application Server, and as
> > Java is my PERSONAL weak point he's playing that card particularly
> > strongly.
> >
> > To give some background. Platform SUN V880 with 4 CPUs and 4 GB
> > memory. Users currently absolute maximum of 50, with growth to 200
> > maximum in 3 years. Typically you'll have about 10-20 users online at
> > any time - but working against very large data sets. ie. Typical
> > Data Warehouse profile - not OLTP where these connection pooling type
> > solutions are a concern.
> >
> > If anything major DBA concerns on the system are security since the
> > data has a very high value, and (currently internal only) if we host
> > services for external clients, they MUST be guaranteed both secure
> > access and complete separation for other client data.
> >
> > Second greatest concern is (unrelated) - we have a potential terabyte
> > database within a year.
> >
> > My gut feeling is (b) every time for the following reasons:-
> >
> > (1) I understand Oracle 9i includes "Virtual Private Databases" which
> > will be difficult or impossible under option (a)
> > (2) Security is a nonsense with every user coming in via a single
> > connection
> > (3) The DBA can't identify individual users so can't monitor them,
> > audit them or kill them if needed (Auditing may be vital in this
> > system !)
> > (4) Option (a) leaves a single connection point and therefore single
> > point of security failure (does option (b) leave several?)
> > (5) Option (a) means the password of the single point of entry must be
> > recorded somewhere accessible from within Java (insecure)
> > (6) Option (a) rules out all Oracle built in object (eg. table) level
> > security, and means the application must re-invent the security model
> > (7) Need I go on?
> >
> > Is there anyone out there who feels differently? Is there a
> > compelling reason for (a) ? Are there any alternatives ?
> >
> > It seems to me the Java Architect thinks I'm being paranoid about
> > security (justifiably so) and protective of my own domain (about as
> > far away from the truth as it's possible to be).
> >
> > Many Thanks in advance,
> >
> >
> >
> > John Ryan
> > (You learn something new every day - sometimes every minute).
>
>
> My feeling (b) is: the single account is going to have CONNECT, RESOURCE and
> DBA roles, and the password will be identical to the username.
>
> Saw that often!
> But of course the system is behind an 'unbreakable' firewall, while studies
> have demonstrated usually the most dangerous persons are *inside* the
> organization.
>
>
> Regards

Speaking as (among other things) a bit of a Java architect, I would first acknowledge the correctness of many of John's concerns. I'm not crazy about this single id business either, for one. It screws up the DB stats as well as creates operational issues; however, the Java concern is the amount of resources tied up in connections, (lots of memory), as well as the resources for creating/destroying them. That's the main reason for conn pooling. Obviously it's not for security.

That being said.......I also don't think an application should depend on the database to do the bulk of security screening. That's kind of far into the app for me.

Regards,
Larry Received on Wed Jun 26 2002 - 11:56:01 CDT