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 VM, a target is created by the Cloud Admin. For Oracle Exalogic, a single target is implicitly configured at install time and no new targets may be created after installation.

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

The reason for this difference is that in Oracle VM, the Cloud Administrator provides shared credentials for Oracle VM Manager. For Oracle Exalogic, 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.3, "Roles and Groups".

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 VM, only the Cloud Admin can perform functions such as creating a target, or viewing the configuration information of a target. For Oracle VM, the Cloud Admin grants permission to Application Admins to use a target.

For Oracle Exalogic, any Cloud Admin may use a configured target, however, they must supply their own credential information to the virtualization system. In Oracle VM, the Cloud Administrator provides shared credentials for Oracle VM Manager.

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 any targets (describeUserTargets and removeTargetUsers) to which they were previously added.

Removing them from the targets 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 Authoring 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 Enabling the Deployer's Authentication and Authorization Model

Perform these steps to enable the Deployer's authentication and authorization model:

  1. A system administrator defines users in LDAP and assigns a Cloud Admin or Application Admin role to those users. These roles control what things a given user can do. This step is done through the Oracle WebLogic Server administrative console.

    You perform the remainder of the operations against the Web service; the Web service calls require Oracle Virtual Assembly Builder user credentials. The Deployer Web service operations that need to be called are as follows:

  2. 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 VM, credentials are supplied here, but for Oracle Exalogic, individual users provide their own credentials in the AddTargetUser step.

  3. 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 VM targets, this operation is only performed by the Cloud Admin and is used to control what users can access the pool. This is a Cloud Admin operation because the credentials supplied by the Cloud Admin must be protected from general users.

    • 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.

  4. uploadAssemblyArchive - This is a Cloud Admin call used to upload an assembly archive to Oracle Virtual Assembly Builder Deployer (note that non-admin users are not allowed to upload assembly archives).

For procedures for configuring Security refer to Section 5.4.1, "Configuring Targets".

3.3 Roles and Groups

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.3.1 Application Admin Group

You create the Application Admins group out-of-band in LDAP.

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

3.3.2 Cloud Admins Group

You create the Cloud Admins group out-of-band in LDAP.

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.3.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.3.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.