| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: .NET, connection pooling and security .
Technically it's a means for doing row-level security in Oracle Apps (in
functional side there's of course more).
It's just a bunch of views on "base" tables. All base tables have "org_id" column in them and the views include a clause where they compare rows org_id to organization id taken from sessions client info. And Forms applications populate the client info during logon.
Tanel.
> What is "Multi-Org"? Sounds like a brand of kitchen utensils?
> On 2003.12.01 00:39, Tanel Poder wrote:
> > 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).
> >
>
>> To REMOVE yourself from this mailing list, send an E-Mail message
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
-- 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).Received on Mon Dec 01 2003 - 00:44:26 CST
 |
 |