Database Reference
In-Depth Information
we do not need to deal with client-side application authentication. However, even in that case, you may
still want to have application authentication for server applications in order to restrict Oracle connection
strings to specific applications.
User for Application Authorization
We need a doorkeeper. He will be our bouncer, rejecting the riff-raff and troublemakers. We will call him
our application verification, appver user. In this analogy, the applications (not people) are our clients.
Some applications are permitted because they have pre-registered and present their identities and
submit to and pass identity checks.
In addition to guarding the entrance, appver provides every successful entrant with the keys needed
to enter the inner doors where they are allowed to go. Again in our analogy, the keys are Oracle
connection strings that have user ids and passwords to connect to Oracle database. These are not
personal users and passwords, but application passwords, permitting secure application roles with
access to application data.
Like a doorkeeper, appver is available to all and has sufficient information to grant passage and
direction. He also has sufficient power to prevent passage, as needed.
A New Profile with Limits and Unlimited
Normally, we would limit user accounts for security, but in setting up our application authorization, we
are going to need some flexibility. We will assign the limits and permissions for this account through a
unique profile, appver_prof , shown in Listing 10-11.
Listing 10-11. Profile for Application Authorization
CREATE PROFILE appver_prof LIMIT
CONNECT_TIME 1
IDLE_TIME 1
SESSIONS_PER_USER UNLIMITED
PASSWORD_LIFE_TIME UNLIMITED
FAILED_LOGIN_ATTEMPTS UNLIMITED;
Note You can find this script in the file named Chapter10/SecAdm.sql .
Contrary to our ordinary standards, our application verification, appver user, will have a password
that will never expire. We will also allow this user to type in the wrong password an unlimited number of
times without locking it out (keeping it from further login attempts, even with the correct password).
And, we will allow this account an unlimited number of concurrent sessions.
I know that all sounds backwards from security, but we have the potential of hundreds of persons
attempting to access applications, verified by this user. We need to tightly control when this password
expires—we will periodically, manually reset the password—some file distribution will probably be
required to the clients. However, we don't want it to expire automatically. Also, we do not know how
many people will concurrently want to authorize for applications, hence the unlimited sessions. Perhaps
down the road, once we have some history, we will know what the correct number of sessions is.
 
Search WWH ::




Custom Search