Configuring SOA Suite 11g with OES - Part 2

As it turns out, there is some more work to do to get a SOA 11g Managed Server to boot and get composites deployed from JDeveloper with the domain enabled with OES.

This whole exercise was greatly simplified by using the Policy Debugging capabilities of the SM.

Once you import the policies from discovery mode, you have to remember to bind the resources into the SM. If you don't, then for the resources that are not bound, you won't get access, but it won't log anything either. With the exception of the oesbpel resource which I'm using for the project, below appears to be the standard list of bindings for the SM in a SOA Suite Domain.


Once you get the bindings set-up, then you'll get proper messages for the resources in the log, but there is one nasty issue that requires a little work to fix. In CP2, you can create the instance in an Organization besides the default. Unfortunately, the discovery mode seems not to be fully in synch with this. The consequence is that for many of the resources that are discovered the privilege does not include the organization. So, you get a whole bunch of ABSTAIN decisions which result in not getting access. I've included a table below that illustrates the changes from the discovered privileges to the correct privileges that the SM uses:

Resource	Discovered Priv	Correct Priv
SOAJMSModule	recieve	RootOrg!someorg!SOAJMSModule!recieve
SOAJMSServer	recieve	RootOrg!someorg!SOAJMSServer!recieve
SOAJMSServer	send	RootOrg!someorg!SOAJMSServer!send
UMSJMSSystemResource	recieve	RootOrg!someorg!UMSJMSSystemResource!recieve
usermessagingserver	execute	RootOrg!someorg!usermessagingserver!execute
ws-pm	execute	any
soa-infra	post	any
shared/adm	access	RootOrg!someorg!shared!access

Notice that for the soa-infra and ws-pm bindings that we have to use the any privilege. This is because OES doesn't allow privs containing '-'. The OES SM uses an action RootOrg!someorg!soa-infra!execute, but you can't enter it. Go Figure! The any action will work just fine. If you really need fine grained control, you could try redeploying the application to a different URI or use the sys_privilege attribute in a constraint.

Finally, make sure to create a role mapping policy that grants the allusers group the Everyone role. It's not set-up by default, but all of the discovered policies are tied to the Everyone role.

Ironically, I don't actually need to secure the domain itself with OES. I need to get the domain enabled with OES so that I can programmatic calls from inside SOA composites. In case you're wondering, the reason why I didn't just keep the Default Authorizer and then add the ASIAuthorizer (OES) is that for unknown resources the ASIAuthorized returns ALLOW and the ASIAuthorizer returns ABSTAIN. This means that is the Adjudicator is set to "Not require unanimous PERMIT", then there is no way for OES to prevent access to resources that the DefaultAuthorizer sees as unknown with out forcing OES to return a DENY. This can make writing policies very complicated.

Now that the set-up is behind me, off to get OES working SOA composites. Stay tuned.