Thursday, August 13, 2009

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.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.