• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 400
  • Last Modified:

dba_users entry for application accounts

If you have an oracle 10g database, residing behind a business application (i.e. for arguments sake let’s say your corporate finance system), is it common for the dba_users to be populated with an account per application user? I thought it would be common for the accounts in dba_users to only be those used for database administration, and perhaps some data analysts, so I was a bit shocked when I noticed anyone who has a login account for the application front end to have an entry in dba_users. Is this kind of authentication common? Does it have a specific name? I assume this is down to how the applicaiton was programmed, as for other apps that have a backend oracle database, there definately isnt an entry is dba_users per application (front end) accounts.
0
pma111
Asked:
pma111
  • 3
  • 2
2 Solutions
 
slightwv (䄆 Netminder) Commented:
dba_users is just a view.  Any Oracle user will be visible in that view.

There are two other level of views:  ALL_ and USER_.  These are restricted based on database permissions.

It is common for applications to be written in such a way that it's usernames and are actually database users.  This let's the database control password maintenance as well as auditing what the users do.

The other way to write apps is that it maintains it's own user table and the app connects to the database using a common username.
0
 
pma111Author Commented:
So would it be fair to say, if the database users arent subject to password expiry, complexity, account lockout etc, then neither will the account that they use to login to the application (which is essentially the same thing). or could you have database accounts, with no expirty, complexity etc policy, however the application is still programmed in such a way that the users have to change their password every so long.
0
 
slightwv (䄆 Netminder) Commented:
>> then neither will the account that they use to login to the application

Good bet.

>>however the application is still programmed in such a way

It's code...  You "can" do whatever you want.

Just not sure why you would want to write code to handle something Oracle handles for free?

You can set up PROFILE's to control all of this.  Then the app just needs to account for the error messages it receives form the database.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
pma111Author Commented:
I assume thats those that are stored within the file dba_users:profile , and then marry those up to the values held in dba_profiles. if say for example password verify function says "default", what exactly does that mean. If it says something else, where can you actually see the password verify function to see what its enforcing.
0
 
slightwv (䄆 Netminder) Commented:
>>I assume thats those that are stored within the file dba_users:profile , and then marry those up to the values held in dba_profiles.

Correct.

>>if say for example password verify function says "default", what exactly does that mean.

Check out: Oracle Password Management Policy [ID 114930.1]

>>If it says something else, where can you actually see the password verify function to see what its enforcing.

It's a stored function.  If it is set, you can view the source just like any other function.

It could possibly be WRAPped (never tried this with a password function).  If so, it's encrypted.  There are claims that WRAPped code can be decrypted but I've never tried.
0
 
DavidSenior Oracle Database AdministratorCommented:
...is it common for the dba_users to be populated with an account per application user?...

I agree with Slight, and would mention that there are alternatives; so it depends upon the architect's preference.  At one end, some applications are written to use generic accounts such as APP_ADMIN for the superusers, and APP_QUERY for the reports and other read-only, and APP_USER for the common access people.  The application / data owner would be responsible for managing which users were given which passwords.  A high-volume site will perhaps look into single sign-on with LDAP.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now