Going in to your Oracle WebLogic Server (WLS) or Oracle Service Bus (OSB) and making configuration changes as the main user (weblogic) is like doing things as root in Unix/Linux. While it is possible, you should avoid it for several reasons. One of those is tracking who made the changes and another is the possibility of locking yourself out of your system due to too many wrong log in tries. What you want to do is to create user accounts for anyone accessing the system and then assigning correct access level to those users. Here is one way of accomplishing that.

Oh and why an external LDAP? Simply because you should not change the Embedded LDAP too much, since it might corrupt at some point and you want to be able to return to the original set up created during domain creation. And also because you already have tools and processes in place
(right?) to handle user accounts and access control to various systems and your WLS/OSB environments should definitely be a part of that ecosystem.

1. Set up the LDAP and populate it with users and groups

Design your groups and add your users to them. Remember that you will need to map the groups to the WLS/OSB roles. You should also have different groups for at least test and production environments, and depending on the size of your set up, you might want to add development environment to that list. It is beneficial to give developers admin rights to your development environment as they will most likely need to tune the server configuration like Java Virtual Machine (JVM) arguments and like.

3. Add the groups to the WLS/OSB roles

This is slightly more tricky than the stuff above, as what we want is to have the users that log in have specific roles. Now the roles that we want to attach the users to are already in place and they have conditions for the built-in groups. The problem is that we cannot use the default groups as they are in the Embedded LDAP and our users are in the External LDAP.

Roles and groups

Role

Group

Description

Administrator

Administrators

WLS admins, can make changes to server configuration etc

Deployer

Deployers

WLS deployers, can install and update JEE applications and resources

Monitor

Monitors

WLS auditors, can look but cannot touch

Operator

Operators

WLS server operators, can restart servers

IntegrationAdmin

IntegrationAdministrators

OSB admins, can do everything in OSB

IntegrationDeployer

IntegrationDeployers

OSB deployers, “Users who are assigned this role can perform all tasks that can be performed by a user in the IntegrationAdmin role.”

IntegrationMonitor

IntegrationMonitors

OSB auditors etc, can look but cannot touch

IntegrationOperator

IntegrationOperators

OSB operators, which is slightly different from WLS operator, as OSB operator can also make configuration changes to Alert rules and destinations etc

So looking at that table, you can deduce that developers should have at least Deployer/IntegrationDeployer roles in the (lower) test environments.
All of this obviously depends on your organisation, contracts and so on.

The XACML data lives in the Embedded LDAP, meaning that you can only make changes to it when the WebLogic Servers are running (yes you could make changes to the ldift files, but please don’t). So start your server and then connect to it and start changing the role conditions. Doing this is slightly wonky if you just start hacking at it, but in the end it is quite
simple:

Things to note about the above. We did not go into edit mode, as the changes we are making are in the Runtime MBean area. We also do not save anything, as all the changes are made immediately to the Embedded LDAP. So essentially the thing that we are doing is overriding the default role condition expression with our own string. The string we use is the name of the default group “Grp(Monitors)” a logical or “|” and the group we have in our external LDAP “Grp(my_monitor_group_in_the_external_ldap)”. Simple, right?

Now, since the Embedded LDAP gets corrupted sometimes, you should keep this script apart from the others, so that you can run this after the accident has happened and you have reset the LDAP. As we just override the expression, we can safely run this script as many times as we want and always get the same result.

4. Profit

Success! You can now administer the people allowed to the system using your regular tools and processes.

When starting an Oracle WebLogic Server using WLST (or Node Manager for that matter) you might see these errors: “oracle.jrf.UnknownPlatformException: JRF is unable to determine the current application server platform” and “JPS-00063: Jps servlet filter creation failed. Reason: java.lang.UnsupportedOperationException”. This is usually the result of two things.

First is that the weblogic.Name=<server name> is not set in the JVM arguments, which is why you might also see this error:

As you can see, the server name in the path is “null”, which would most probably be incorrect (unless you have a very exotic naming standard). You will need to have this in the JVM arguments “-Dweblogic.Name=<server name>”.

The second is that you will need to located be in the domain root directory (e.g. /domains_home/domain_name/) when you start the weblogic.Server instance. The setDomainEnv.sh will do this for you, but if you do not call that script, then you will need to take care of this by changing the directory to the correct location before doing your thing. The Node Manager will take care of this for you, but for example WLST startServer will not.

Oh WLST how I love thee, let me count the ways.. Even thought the scripting is something you can and should do, there are times when doing it manually, i.e. using the graphical tools, is still preferred. When is that time? When you have spent countless hours trying to create a new clustered domain with exactly the correct and wonderful configuration that you require. And sometimes even when you could do with just the bare bones, vanilla as they come, single cluster domain.

So the WLST script for creating a clustered domain is simple, right? You just do this:

readTemplate(WL_HOME + ‘/common/templates/wls.jar’)

<create clusters and managed servers etc>

writeDomain(DOMAIN_HOME)

Easy as 1-2-3. As long as you are not making an Oracle Service Bus domain, because that process has some serious issues. There are some attempts to fix this, but here is a way of doing it with the standard OSB templates.

So the magic lies in the retargeting of everything. How to do that? The answer is in the wi^H^HOracle Forums, where someone named PetervanNesatTheFutureGroup gives a nice partial answer to that question. What it boils down to, is using the WLST Offline commands for listing the resource names, looping through that list of names and then using those names to access and changing the resources. And the reason to do all of this, is because the OSB templates do not target the resources correctly to the defined environment, even though they should.

List of resources you will need to retarget:

Some of the Application Deployments

All of the Libraries

All of the Startup classes

All of the Shutdown classes

So what is the application list that you will need to retarget? Well, for the first Management Server only (these are the singleton services), you target: ALSB Cluster Singleton Marker Application, ALSB Domain Singleton Marker Application and Message Reporting Purger.

Everything else is targeted to both Admin server and the cluster. And there you go, you have a correctly formed, clustered Oracle Service Bus domain. Oh and by the way, it would seem that the old bug which left out the XACMLAuthorizerInit.ldift and DefaultAuthorizerInit.ldift files from an OSB domain created from the templates has been fixed. Which is just super!