One key area of concern when it comes to our IT infrastructure continues to be security, in particular user security. In the Oracle world, this concern exists at all levels from the front-end applications, to the middle tier level we use for deployment, to the back end tier or database layer, to the tools that we use to manage the entire infrastructure. To this end, in Cloud Control, Oracle has introduced some new features, and strengthened some of their existing functionality to help us ensure the security of Oracle’s primary IT infrastructure DBA management toolset.
Essentially there are four major aspects of user security within 12c that I am going to review in this article. They are Cloud Control Authentication, Cloud Control Authorization, Credential Management and Target Authentication. In this article, we’re going to look at the first two of these areas, Cloud Control Authentication and Authorization. Next month, we’ll look at Credential Management (including one of my favorite new features in EM, which is Named Credentials) and Target Authentication.
Cloud Control Authentication
Simply defined, authentication is the action of ensuring that any user attempting to connect to EM has a valid account and has provided the correct login credentials.
EM provides many different ways of configuring authentication for users to log into Cloud Control.
Oracle Access Manager (OAM) Single Sign On
EM can be configured to work with an existing Oracle Fusion Middleware Single Sign On solution using its Enterprise Directory Identity Stores. For additional information and documentation on setting up OAM SSO – please refer to the Oracle Fusion Middleware Administrators Guide for Oracle Access Administrator.
Single Sign On Authentication
EM can be also be configured to use Oracle Application Server’s Single Sign On functionality. Any OAS SSO user can be registered as an EM administrator. You can follow this link to get more information on SSO
Enterprise User Security Authentication
We can use Enterprise User Security where user accounts are created and stored in an LDAP compliant directory server. After configuring the repository with EUS, we can configure EM to use EUS as its authentication option. If you would like additional information on configuring EUS, please click here.
Oracle Internet Directory (OID) Authentication
OID is an LDAP compliant directory that is created based on an Oracle database, which is fully integrated into both Oracle Fusion and Oracle applications.
Microsoft Active Directory Authentication
In a Windows environment, Microsoft Active Directory can be configured to be the identity store and EM can be configured to use it as the authentication tool.
EM Repository Based Authentication
The default option for EM authentication is to create administrator accounts within EM (which are database user accounts). This method allows us to take advantage of database password management and complexity rules and the use of a database password file.
Each administrator account that is created has a user name, password, password profile. Target privileges, resource privileges and roles are then granted to the user account.
To access the Create Administrator page – select the Setup Menu, and then Security, then Administrators:
Create Administrator: Properties
You can indicate if this user is to be a Super Administrator in EM; also there is an option to not allow this user to change their own password. The subsequent steps in the wizard are used to assign the appropriate privileges to the user account.
Cloud Control Authorization
Just like trying to manage some 200+ system privileges in a database across hundreds of users can be an administrative nightmare, trying to manage the privileges on potentially hundreds (and maybe even thousands) of targets across even a small group of users in EM can also be a cause of migraines for the EM administrator. At the same time, giving the same blanket level of access to all EM administrators is an exceedingly dangerous option (not to mention this would probably break just about every security rule out there).
Thankfully, with its combination of Authentication Schemes, User Classes and Privileges and Roles, EM can make this somewhat arduous task much simpler, and also much faster.
Authentication Schemes
These are the authentication options set up for a particular target or target type. For example, host targets can use username/password, PKI infrastructure or even something like Kerberos. Databases can use a different scheme as can any kind of target. In fact, each target type could be set up to use a different Authentication Scheme in EM.
EM User Classes
There are three levels or classes of users that can be created and managed by EM. Super Administrators, Administrators and the repository owner.
Super Administrators
Any user created as a super administrator has full access to all targets as well as full access to all of the administrator accounts. The default Super Administrator account is SYSMAN and is created when Cloud Control is first installed. Only the Super Administrator can create other Administrator Accounts.
Administrators
These are the regular administrator accounts that are created in EM. The activities and targets that an administrator can access are controlled and governed by the roles, system and target privileges that are granted specifically to the account by the Super Administrator.
Repository Owner
This is the database administrator account that owns the EM repository. This account can not be deleted, modified or duplicated. This is the same SYSMAN account that is the default Super Administrator.
Privileges and Roles
Privileges are the basic layer of access control for Administrators in EM. Just as in the database, an EM role is a named collection of privileges. There are 25 out-of-the-box roles that come pre-defined in 12c Cloud Control. Additionally, custom roles can be created to more specifically manage any of the privileges.
Privileges fall into two categories – target and resource.
Target privileges allow the user to perform activities on a specific target. Within target privileges there are those that apply to all targets, for example, full_any_target would give the privilege to do all operations on a target including removing the target altogether while view_any_target is simply the ability to look at a target’s information without being able to make any changes.
There are also target privileges that are applied only to a single target such as full_target or view_target. When assigning these, the super administrator must indicate the specific target.
Resource privileges on the other hand allow the administrator to do operations against a resource rather than a target. For example, there are a series of privileges that allow users to work with Jobs in EM. These include full job privileges, edit job privileges (which does not allow a job to be deleted), view jobs and so on. These are essentially about using the features within EM rather than being able to access and manage a specific target being monitored by EM.
Needless to say, when it comes to managing user authorization, the biggest challenge is planning. Who needs what and why…and do we grant the privilege direct, or do we create our own roles and manage through them? No easy answers to this question. At least we know that EM has all the functionality to allow us to control how the users are going to be authenticated, and also allows us to restrict what they can do once they are successfully logged in.
