Re: .NET, connection pooling and security .

Multi-Org in Oracle Applications works (well) with this client info setting and views having where clauses on client info.

Tanel.

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Monday, December 01, 2003 6:19 AM

> I like the idea of setting the client info.
> The consensus on the other stuff is that's just the way it is.
>
> thanks,
> steve
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Saturday, November 29, 2003 11:34 PM
>
>
> >
> > On 2003.11.29 22:49, Steve Perry wrote:
> > > I hope somebody on the list can help me out with this.
> > >
> > > All of our 3-tier apps are architected with a schema owner (owns all
> objects
> > > used by an application) and application user (no create privs, but it
> does
> > > have full dml privs to the schema owner objects).
> > > On the web side, connection pooling is setup with 10 connections
logged
> in
> > > (all as the application user).
> > > When users connect, the application reads some active directory keys
> that
> > > tell if the user is a reader, dml user or admin user (all privs).
> > >
> > > I don't feel the application should be managing security and I'd like
to
> > > take that responsibility away.
> > > The 10 identical connections logged into the database bothers me too.
> > >
> > > I'd like to make it work similar to our 2-tier apps where we use
roles,
> > > assign them to a user and they connect individually. We don't have OID
> setup
> > > and I imagine that would solve this. Short of that, is there any other
> way
> > > to work around having the 10 identical connections logging in and
having
> the
> > > application maintaining security? Is there another way of assigning
the
> > > security?
> > >
> > > I don't have any web development experience and I thought I'd check
here
> > > first to see how others deal with this. I hope somebody else has
> worked
> > > this out at their shop.
> > >
> > > I'm not sure if the answers will change, but it's an all M$ shop,
except
> for
> > > Oracle.
> > >
> > > Any help would be appreciated.
> > > Steve
> > >
> >
> > Steve, I am not a .NOT user or admirer but I think that all security
> should be in one place because
> > then it is non-conflicting and more easily controlled. If the business
> decision is made that this place is
> > LDAP, then you don't have much choice.
> > For the sake of the DBA staff, you can adopt a standard mandating that
> every application should call
> > DBMS_APPLICATION_INFO.SET_CLIENT_INFO immediately after it connects to
the
> database.
> > Client info information is visible from V$SESSION so you can use
> alternative means of determining
> > sid and serial#. What does seem as an objectionable practice is
granting
> "admin" authority through
> > LDAP. Only DBA should have DBA role and nobody else. Hopefully, this
> "admin" role granted through
> > the active directory does not mean "DBA", but only "application admin".
> Application admins are helpful
> > people who know the application and administer certain parts of it. They
> can take the burden of
> > mundane tasks like granting & revoking roles as well as creating users
> away from the DBA and
> > have him working on more important tasks like helping developers,
> documenting best practices,
> > planning disaster recovery, setting standards, planning upgrades and
> tuning buffer cache hit ratio.
> > In other words, everything seems to be hunky dory except the posibiliity
> that the DBA role is granted
> > away lightheartedy. You are a DBA and as a DBA, you took the oath of
> enforcing the first DBA commandment
> > which reads:
> > Thou shalt not have other DBAs but me.
> >
> > No ifs, no buts, no active directories here.
> >
> >
> >
> > --
> > Mladen Gogala
> > Oracle DBA
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Mladen Gogala
> > INET: mgogala_at_adelphia.net
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Steve Perry
> INET: sperry_at_sprynet.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).