Skip Headers
Oracle® Virtual Assembly Builder User's Guide
11g Release 1 (11.1.1.6.2)

Part Number E49281-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Security

This chapter describes the security of Oracle Virtual Assembly Builder, and contains the following sections:

3.1 Resources

The resources describe in Table 3-1 are protected:

Table 3-1 Resources

Resource How protected

Target

For Oracle Exalogic, a single target is implicitly configured at install time and no new targets may be created after installation.

Any Cloud Admin may use a configured target, however, they must supply their own credential information to the virtualization system. The single implicitly configured target only includes the target URL

Only a Cloud Admin may view the configuration information of a target.

Credentials (passwords and keys)

Encrypted

Assembly archive in the Deployer

Protected by the "owner" concept, see Section 3.2.2, "Assembly Archive Authorization".

Assembly instances and deployment plans in the Deployer

Protected by the "owner" concept, see Section 3.2.2, "Assembly Archive Authorization".


3.2 Security Model Employed by Deployer

Oracle Virtual Assembly Builder Deployer is constructed as an application running in the Oracle WebLogic Server container and leverages the security infrastructure provided by Oracle WebLogic Server. Oracle WebLogic Server is configured with the embedded LDAP authenticator by default but you can reconfigure Oracle WebLogic Server to point to an external corporate LDAP. The Deployer depends upon Oracle WebLogic Server users being put into one or both of two groups: Cloud Admins or Application Admins.

For information on creating the Cloud Admin and Application Admin groups and roles, see Section 3.2.4, "Using Oracle Virtual Assembly Builder Deployer with External LDAP".

Having a user in those groups allows them to be mapped to having the roles needed by the Deployer: Cloud Admin or Application Admin. The Deployer's access control requires that a user be in one or both of those groups. When you set up a connection to the Deployer using abctl you must specify a username and password for an Oracle Weblogic Server user that has been added to one or both of those groups.

When a user attempts a Deployer operation using either Oracle Virtual Assembly Builder Studio or abctl, they are authenticated using the connection information and then once authenticated their request goes to the Deployer's Servlet running in the WLS Servlet Container. The servlet checks that they are in one of those roles and then performs additional checks (for example, whether the user is allowed to access the specified target, or whether the user is allowed to access the specified assembly archive).

Oracle Virtual Assembly Builder Deployer uses Oracle WebLogic Server capabilities for access checking, however, Oracle Virtual Assembly Builder Deployer does not have visibility on the LDAP information for managing those identities. Due to this circumstance, it is possible for you to delete a user out of Oracle WebLogic Server while Oracle Virtual Assembly Builder configuration referencing that username is still in place.

Caution:

Once an Oracle Virtual Assembly Builder request has moved beyond the authentication and access checking described above, it will continue to completion even if the user information is removed from the WebLogic Server authentication store.

3.2.1 Target Authorization

For Oracle Exalogic, any Cloud Admin may use a configured target, however, they must supply their own credential information to the virtualization system.

Caution:

If a user is removed from the Oracle WebLogic Server authentication store, you must remove any cached information about that user from the Deployer by removing that user from the target (describeUserTargets and removeTargetUsers) to which they were previously added.

Removing them from the target in the Deployer removes any cached information for that user from the Deployer. This prevents a situation where a user has cached information, the user is removed from Oracle WebLogic Server, a different user of the same name is added into Oracle WebLogic Server and the new user inherits all the previous user's cached information in the Deployer.

3.2.2 Assembly Archive Authorization

When you attempt to access an assembly archive, the Deployer performs a check. The following users are granted access:

  • A user with the OVAB_ADMIN role.

  • The owner of the assembly archive. The first user to upload the assembly archive becomes the owner.

3.2.2.1 Authorizing Additional Users with the addAssemblyUsers Command

You can authorize additional users, adding them to the access list, using the addAssemblyUsers command. Only a user with the OVAB_ADMIN role or the assembly archive owner can perform this operation.

Only the Application Admin who is the owner of the assembly archive can manage it by adding/removing/describing assembly users, deleting the assembly or updating the assembly archive. The users in the assembly access list can use the assembly by viewing, downloading, registering and creating assembly instances (assuming they also have access to the target).

3.2.2.2 Assembly Instances

The user who creates an assembly instance is its owner. Besides the Cloud Admins, only the assembly instance owner can manage and use an assembly instance.

3.2.2.3 Assembly Resources

The uploadAssemblyResources command is controlled by a security policy. A resources file may or may not contain scripts. If the resource file does not contain scripts, a user on the assembly access list can run the command. If the resource file does contain scripts, only the Cloud Admin user is allowed to run the command, to prevent a malicious attack.

When including scripts in the resources files, the lifecycle names that are supported are: pre-deploy, post-deploy, deployer-pre-app-config, deployer-post-app-config, deployer-pre-vm-start, deployer-post-vm-start, deployer-pre-vm-stop, deployer-post-vm-stop, pre-undeploy, post-undeploy. You can create corresponding script folder names.

3.2.3 Using Oracle Virtual Assembly Builder Deployer with Embedded LDAP

By default, Oracle Virtual Assembly Builder Deployer uses the Oracle WebLogic Server Embedded LDAP and in this case, the roles and groups needed by Oracle Virtual Assembly Builder are preconfigured.

To begin using Oracle Virtual Assembly Builder, you must first add users through the Oracle WebLogic console and then add those users to either the "Application Admins" group and optionally the "Cloud Admins" group if you want to allow that user to perform administrative operations in the Deployer.

3.2.4 Using Oracle Virtual Assembly Builder Deployer with External LDAP

Oracle Virtual Assembly Builder defines security roles and groups. The product installer sets up the roles and groups for the embedded LDAP case and you create the users and add them to the groups through the Oracle WebLogic Server console.

Follow this process to create roles and groups:

  1. Use the procedures in Oracle® Fusion Middleware Securing Oracle WebLogic Server to configure Oracle WebLogic Server for external LDAP.

  2. Create groups for "Cloud Admins" and "Application Admins" in the LDAP server.

  3. Add the users defined in the LDAP server to these groups.

  4. Place the groups into the security roles using the role expression Grp(GroupName|GroupName|GroupName).

    The process of computing and granting roles in Oracle WebLogic Server is referred to as role mapping. An access decision is the component of an Authorization provider that determines whether a subject has permission to perform a given operation on a WebLogic resource. (See "Access Decisions" in Developing Security Providers for Oracle WebLogic Server, in Oracle® Fusion Middleware Securing Oracle WebLogic Server).

3.2.4.1 Application Admin Group

You create the Application Admins group out-of-band in LDAP through the Oracle WebLogic Server console hosting the Deployer.

You create Application Admin users out-of-band in LDAP. You include members of this group into the Application Admin group.

3.2.4.2 Cloud Admins Group

You create the Cloud Admins group out-of-band in LDAP through the Oracle WebLogic Server console hosting the Deployer.

You create Cloud Admin users out-of-band in LDAP. You include the users in the Cloud Admins group, which results in the Cloud Admin role being assigned at login.

3.2.4.3 Cloud Admin Role

You create the Cloud Admin role by an auth-constraint in the web.xml and a security-role-assignment of the Cloud Admins group to the Cloud Admin role in weblogic.xml.

3.2.4.4 Application Admin Role

You create the Application Admin role by an auth-constraint in the web.xml and a security-role-assignment of the Application Admins group to the Application Admin role in weblogic.xml.

3.2.5 Configuring Targets and Target Users

Perform these steps to configure targets and target users:

  1. createTarget - This operation, which can only be performed by the Cloud Admin, defines the connection information, and, depending on the backend type, user credentials for the backend. For Oracle Exalogic, individual users provide their own credentials in the AddTargetUser step.

  2. addTargetUser - Depending on the backend type, this may be a Cloud Admin call or Application Admin call, due to differences in the security models of the backend systems.

    • For Oracle Exalogic targets, this is a user operation and is used to specify user credentials (in this case, the Cloud Admin does not have to give specific access because the backend will be checking the credentials). This is an Application Admin call because the user's credentials must be protected from others, including the Cloud Admin.

For procedures for configuring Security refer to Section 5.4.2, "Adding Users to the Target".

Once configuration is complete, you would next perform uploadAssemblyArchive. This call may be made by either a CloudAdmin or ApplicationAdmin user. The first user to upload the archive is the owner of the archive. Only the archive owner or users added using the addAssemblyUser command may upload new versions of the archive or create assembly instances based on the archive.