This chapter describes the security of Oracle Virtual Assembly Builder, and contains the following sections:
The resources describe in Table 3-1 are protected:
| Resource | How protected |
|---|---|
|
Target |
For Oracle VM, a target is created by the CloudAdmin. For Oracle VM, the CloudAdmin grants permission to ApplicationAdmins to use a target. In Oracle VM, the CloudAdmin provides shared credentials for Oracle VM Manager. Only a CloudAdmin 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.3.2, "Assembly Archive Authorization". |
|
Assembly instances and deployment plans in the Deployer |
Protected by the "owner" concept, see Section 3.3.2, "Assembly Archive Authorization". |
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 using the Oracle WebLogic Server Administration Console.
Follow this process to create roles and groups:
Use the procedures in Oracle® Fusion Middleware Securing Oracle WebLogic Server to configure Oracle WebLogic Server with an external LDAP server.
The groups "CloudAdmins" and "ApplicationAdmins" are automatically created at installation. Add the users defined in the LDAP server to these groups.
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 operation made by 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 for more information.
The ApplicationAdmins group is created automatically at installation.
You create ApplicationAdmin users out-of-band in LDAP. You include members of this group into the ApplicationAdmins group.
The CloudAdmins group is created automatically at installation.
You create CloudAdmin users out-of-band in LDAP. You include the users in the CloudAdmins group, which results in the CloudAdmin role being assigned at login.
You create the CloudAdmin role by an auth-constraint in the web.xml and a security-role-assignment of the CloudAdmins group to the CloudAdmin role in weblogic.xml.
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: CloudAdmins or ApplicationAdmins.
For information on creating the CloudAdmin and ApplicationAdmin groups and roles, see Section 3.2, "Roles and Groups".
Having a user in those groups allows them to be mapped to having the roles needed by the Deployer: CloudAdmin or ApplicationAdmin. 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.
For Oracle VM, only the CloudAdmin can perform functions such as creating a target, or viewing the configuration information of a target. For Oracle VM, the CloudAdmin grants permission to ApplicationAdmins to use a target.
In Oracle VM, the CloudAdmin 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.
When you attempt to access an assembly archive, the Deployer performs a check. The following users are granted access:
A user with the CloudAdmin role.
The owner of the assembly archive. An assembly archive corresponds 1:1 with an assembly version and an assembly may have multiple assembly versions. The user who uploads the first assembly archive for an assembly (version 1.0) owns the assembly.
Additional users can be granted access to an assembly.
You can authorize additional users, adding them to the access list, using the addAssemblyUsers command. Only a user with the CloudAdmin role or the assembly archive owner can perform this operation.
Only the ApplicationAdmin 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).
The user who creates an assembly instance is its owner. Besides the CloudAdmins, only the assembly instance owner can manage and use an assembly instance.
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 CloudAdmin 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.
Perform these steps to enable the Deployer's authentication and authorization model:
A system administrator defines users in LDAP and assigns a CloudAdmin or ApplicationAdmin 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:
createTarget - This operation, which can only be performed by the CloudAdmin, defines the connection information, and, depending on the backend type, user credentials for the backend. For Oracle VM, credentials are supplied here.
addTargetUser - Depending on the backend type, this may be a CloudAdmin call or ApplicationAdmin call, due to differences in the security models of the backend systems.
For Oracle VM targets, this operation is only performed by the CloudAdmin and is used to control what users can access the pool. This is a CloudAdmin operation because the credentials supplied by the CloudAdmin must be protected from general users.
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.
For procedures for configuring Security refer to Section 5.4.2, "Configuring Targets".