One new feature in SOA Suite 12c I had not seen anyone discuss yet is partition level security. In 11g, partitions only allowed you to group composites logically and provided control for starting, stopping, and undeploying at the partition level. In 12c, Oracle has added the ability to provide groups of users specific permissions on each partition, including viewing, deployment and administration.
For customers trying to provide a shared infrastructure environment, this now allows them to have users from each group manage their own partition and instances while not having access to the other partitions. This can also be helpful in development environments with multiple teams working on multiple projects.
In the following example I have created 3 partitions in my SOA domain:
| PARTITION | DESCRIPTION |
|---|---|
| Common | Shared services, managed by SOA administrators |
| HR | HR services and processes, managed by HR team |
| Finance | Finance services and processes, managed by Finance team |
In this example, a group of SOA administrators will have full access to the domain, while HR and Finance administrators should only have access to their respective partitions. I have created the following Weblogic groups in order to accomplish this:
| GROUP | DESCRIPTION |
|---|---|
| SOA Admin | Administrator on all partitions |
| SOA Monitor | Monitor only permissions on all partitions |
| HR Admin | Administrator on HR partition |
| HR Monitor | Monitor only on HR partition |
| Finance Admin | Administrator on Finance Partition |
| Finance Monitor | Monitor on Finance Partition |
Each of these weblogic groups is also a memeber of the Monitors group. This is required so that users can log in to Enterprise Manager. A user must have at least one Weblogic administrative role to login to EM. Once they are logged in their access will be controlled using finer grained permissions and application roles.
I also created a single user in each of these weblogic groups for testing purposes.
Now that all weblogic users and groups have been created, the groups need to be assigned to the correct application roles within EM.
First you will need to login as the weblogic user, right click on soa-infra and choose Security -> Application Roles
You will see a set of application roles for SOA level permissions as well as a group for each of your partitions. Below you can see the SOA roles and the roles for the Finance partition.
Now, we will assign the following Weblogic groups to the following application roles:
| WEBLOGIC GROUP | APPLICATION ROLES |
|---|---|
| SOA Admin | SOAAdmin |
| SOA Monitor | SOAMonitor |
| HR Admin |
HR_Deployer HR_Tester HR_ApplicationOperator |
| HR Monitor | HR_Monitor |
| Finance Admin |
Finance_Deployer Finance_Tester Finance_ApplicationOperator |
| Finance Monitor | Finance_Monitor |
The deployer and tester roles for each partition are not included as part of the ApplicationOperator role, so we have included all 3 of these roles for our Admin groups.
Your roles should now look like the examples below:
Now that we have all of our permissions configured properly we can log in with some of our test users to see the outcome of our configuration.
First, I will login as the hrmonitor user who is in the HR Monitor group. You can see that this user only sees the HR partition under soa-infra and can view the information about this partition.
If this user tries to view soa-infra level details, most are unavailable:
If we login as the Finance Admin next, we can see that now the Finance partition is the only one visible and that if we browse to a composite in this partition we also have the ability to start and stop and test the composite.
Now we will login as the SOA Monitor. You can see that all partitions are visible, but the composites cannot be controled or undeployed as the monitor user.
Lastly, we will login as the SOA Admin user. This user can see everything the SOA Monitor user could, but now also has permission to deploy/undeploy and control all composites.
By providing fine grained permissions for each partition this allows customers to more easily share a single SOA domain while still limiting the access that different groups have to it. Even in a development environment it can be important who has the ability to deploy and undeploy composites in each partition, while in production it can be very useful to control who has visibility into the flow traces of different partitions.