I think the real issue is who is going to keep the usernames and passwords
maintained. Is it you? Do you have that much spare time? Also, it can also
be inefficient with everyone's time. Someone gets hired. Their supervisor
sends you an email so you can create the userid. But wait, they forgot to
I worked with one vendor's application that had a security administrator role. The
security administrator (not a DBA) had privileges to create Oracle users and grant
necessary permissions. The security administrator functions were all handled through
the vendor front end software. The
Another suggestion is to create an Application Administrator. Create a user template
for them w/ default privs, default tbs, etc. Grant the app admin create/alter user
privileges and let them manage the user community.
hth,
Gene
[EMAIL PROTECTED] 07/31/02 12:25PM
I worked with one
I don't think administering usernames should be the DBAs responsibilty. There
are better things to do than create/manage hundreds of users.
But there are applications (for instance Siebel) which require you to create
individual logins for each user. We have handled that by creating a
The DBA usually does not get to decide how the application is developed in
most of the cases. We have to manage what's out there. There are some products
which use one login for all users and manage security within the application.
If the applications is web enabled, the changes are the
Title: RE: Ids and passwords for application users
-Original Message-
From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]]
I think the real issue is who is going to keep the usernames
and passwords
maintained. Is it you? Do you have that much spare time?
At my previous employer
Title: RE: Ids and passwords for application users
Peter,
not clear on if the database is going to be used by developers doing
development work or will an application use it and you'll have up to 300
application users?
If it's an application, how about making one account that owns all
If a common login is used (which is the case with most applications),
dbms_application_info can be used to set the actual username in either the
module or action. As long as the application is not using dbms_application_info
to set both, you should be able to get the info from v$session.
Title: RE: Ids and passwords for application users
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
If a common login is used (which is the case with most
applications),
dbms_application_info can be used to set the actual username
in either the
module
--Create roles for the possible user types.
--Grant permissions to the roles.
--Create induhvidual lusers in the database.
--Assign the appropriate role to the appopriate luser.
Anything else can quickly become a maintenance/monitoring nightmare. This
is why roles were rolled out.
Scott Shafer
Peter - Go with option #1 unless you relish a career as an Oracle security
officer. With option #1 the developers can create some administrator
screens. Unless security is really, really critical.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Monday,
Title: RE: Ids and passwords for application users
I always preferred the option of having a userid for each person, because it makes it easier to match session to user. When you say userid dwilliams locking a table you know who to call, but if you see userid app_user you have to do some
Title: RE: Ids and passwords for application users
trying
to understand how oracle 9i proxy authentication work.
is
anyone using it?
-Original Message-From: Jacques Kilchoer
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 29, 2002 4:28
PMTo: Multiple recipients of list ORACLE
13 matches
Mail list logo
