Dear Readers,
My name is Franz Devantier, creator of this blog. I am an Oracle Certified
Professional (OCP DBA 11g) Security DBA.
I will be sharing with you the basic duties of an Oracle DBA, and also
some of the undocumented, and not so well known tasks.
I will make a deal with you: If you refer me to a company that needs
database support, from a few hours per week to full time, and I am able to sign
a contract with them.
Then I will give you 10% of the monthly
contract or deal price every month. When
the contract ends, and we re-sign the contract, I will again give you 10% of
the monthly contract price. This will go
on until the company no longer employs or contracts me or my agents to look
after their databases.
I can do this, because that 10% is my
marketing budget. When we re-sign the
contract, in the future, it may depend on you giving the thumbs up again, and
that is worth 10% of the monthly contract price, to be given to you as
commission.
Contact:
Franz
Security
Administering Authentication - Part 3
Creating a User Who Is Authorized by a Directory Service
There are two main ways to create users who are authorized
by a directory service. You can create
the users with a private schema, or with a shared schema.
Private Schemas
You would create a global user with a private schema like
this:
SQL> CREATE USER fred
IDENTIFIED
GLOBALLY AS ’CN=fred,OU=division1,O=oracle,C=SA’;
The string in the AS clause provides an identifier that is meaningful
to the enterprise directory, the identifier or ‘Distinguised name’ or DN.
With the above arrangement user fred is a Global user, but
he must be created in every database that he must access, plus the directory.
Shared Schemas
To work around this problem of having to create each user
in every database that they must access, Oracle provides one solution, and that
is shared schemas. In a shared schema,
multiple enterprise users share a single schema in the database. These users will be authorized by the
enterprise directory service.
So you will need to create a Schema-Independent user:
1. Firstly you create a shared schema in the database.
SQL> CREATE USER shared1 IDENTIFIED GLOBALLY AS ’’;
2. Secondly in the directory service, you will now create
multiple enterprise users, as well as a mapping object. The mapping object will communicate to the
database, how you want to map your enterprise users DN’s to the shared schema.
You can do a full DN mapping, which is one directory entry
for each unique DN.
Alternatively you can map all the uses containing certain
credentials to the ‘shared1’ schema, or more correctly certain DN components to
the ‘shared1’ schema:
OU=division1
O=oracle
C=SA
The CN attribute is left out, because that would have
specified the specific database schema.
Most users, especially application users do not need their
own schemas, so implementing schema-independent users divorces users from the
databases. So to implement this you
create multiple enterprise users, that access the shared schemas in a number of
databases throughout the enterprise.
Advantages of Global Authentication and Global
Authorization
-> You can implement strong authentication using SSL,
Kerberos, or Windows Server native authentication.
-> Enables the centralization of authentication, and
management of users and privileges across the enterprise.
-> Shared schemas especially make it easier to
administer, because you don’t need to create schema’s for every user in every
database in the enterprise.
-> Single sign-on becomes possible with this
arrangement. Users only need to sign on
once, and then they have access to multiple database, services, and
applications, across the enterprise.
-> Global user authentication and authorization provide
password-based access. This means that
previously defined password authenticated database users, can be migrated to
the directory services, by means of the ‘User Migration Utility’. This means that even prior Oracle release
clients can make use of Global Authentication and Authorization.
-> A local user can connect in the context of a global
user when executing a stored procedure over a database link, ie CURRENT_USER
database links can connect as a global user..
This is done without storing the global user password, in a link definition
anywhere, which makes things more secure.
Proxy Authentication and Authorization
Oracle provides three forms or types of proxy
authentication.
-> The middle-tier sever will authenticate itself with
the database server, and also with the client.
The application user or an application authenticates itself with the
middle-tier server. With this
arrangement, the client identities can be maintained all the way through to the
database.
-> The client may not be authenticated by the
middle-tier, in the case where the client is a database user. The client’s identity and password are passed
through the middle-tier server, and through to the database server for
authentication.
-> A Global user, the client, is authenticated by the
middle-tier server, and passes information through the middle-tier in order to
retrieve the client’s credentials or username.
For example:
- Distinguished Name (DN)
- Certificate
In all of the above scenarios, the middle-tier must be
authorized to act on behalf of the client by the administrator. In order to authorize a middle-tier server to
proxy a client, use the GRANT CONNECT THROUGH clause of the ALTER USER
statement. You can also specify roles
that the middle-tier is permitted to activate when connecting as the client. Note that operations done on behalf of a
client and by the middle-tier are auditable.
You can query the PROXY_USERS data dictionary view to
establish which users are currently authorized to connect through a
middle-tier.
To disallow a proxy connection, you can use the REVOKE
CONNECT THROUGH clause of the ALTER USER statement.
Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com
Classifieds
No comments:
Post a Comment