First time users of OES sometimes run into problems and get stuck on policy distribution. Most often these problems are caused because of network issues. In this blog post I will go over how OES policy distribution works and why it behaves in certain ways. Hopefully this will come in handy, when you are trying to setup OES.
OES has Admin and SM components. Admin is primarily used for managing authorization policies (i.e. policy CRUD). Users can rely on the Admin Web UI or the command line tools for managing policies. OES SM consists of the runtime authorization engine which computes authorization decisions (i.e. PDP) and it might also do policy enforcement (PEP). When a user logs into OES Admin, modifies policies and distributes them, the policies need to be pushed to the SM.
It will be good to take a step back and see how OES Admin and SM “know” each other. When a new SM is created (this step is called SM configuration), we first need to establish trust between OES Admin and SM. Trust is important because Admin distributes authorization policies to SM. Establishing proper trust ensures that a rouge SM cannot discover your company’s authorization policies.
When setting up SM, the configuration tool creates an SSL connection from SM to Admin and establishes trust and establishes trust by exchanging certificates (a keen reader would have noticed that the SM configuration tool asks for OES Admin password, this is required to establish 1-way SSL to exchange certificates). This is an important step, because any failure here means that OES Admin and SM will not trust each other. Failure to establish trust will be perceived as a policy distribution problem because Admin refuses to distribute policies when it sees that the SM is not trusted.
When SM starts us for the first time:
1) SM send a request to OES Admin that it needs the latest set of authorization policies. This request includes
a) Version number of the current policies: Because SM is starting
up for the first time it does not have any policies. So this version
number will be 0
b) Host name of the machine where the SM is running. SM gets
this information using “getLocalHost().getHostName()” call
c) Port number used by SM to listen for policy updates from Admin
2) The SM continues to come up. In OES 11g, when SM does not have any policies the PDP gives a “deny” to all authorization requests
3) The admin will record the SM’s host name, port number and policy version number in the SM registration table.
4) The admin notices that there are newer policies for the SM. So the Admin opens a TCP connection to the SM and sends the latest set of policies to SM
Common sources of policy distribution problem
1) Initial enrollment did not complete successfully: The common symptom of this problem is that OES Admin will print messages (on the command line) complaining about bad certificates
2) Improperly configured firewall between the admin and SM: Remember that OES Admin and SM open connections to each other. OES Admin listens on the same port number as WLS Admin and SM’s listener port number will be in its jps-config.xml file. This problem is usually perceived as a connection issue at OES Admin or SM
3) Improperly configured network (or http) proxy: This messes up connectivity between Admin and SM. The problem is often perceived as an SSL certificate error.
4) Host-names or DNS incorrectly configured: Things get more complex when the host which is running SM has multiple names and is multi-homed. The easiest way to debug this is by looking at the Policy Distribution screen. If the SM host name on the screen is messed up, it means the SM is sending bad information to the Admin. Which in-turn means that the host name is configured incorrectly on the SM machine.
In this blog post I have written about some common problems. Let me know if you have run into any other types of issues with policy distribution and I will be happy to add them to this blog post.
HI Subbu,
Thanks for providing good info on OES through the blog.
I am looking for integrating OES with web services(authorization for service operations) and database. Can you please refer me to any relevant documents for these.
Thanks,
Anumolu.
Hi Subbu –
Thanks for providing very useful insights into OES in your posts.
We have associated a FMW 11.1.1.6 (PS5) domain (a simple JRF based domain) to the OES 11gR1 policy store. The policy store is an Oracle database. The policy store got configured successfully in the domain’s jps-config.xml, and we disabled the “audit” service as recommended.
We are trying to use the PEP API from our ADF application to programmatically get the authorizations from OES (for an policy available in OES) for a particular subject and handle the returned decision. As per documentation in Chapter 6 of Oracle® Fusion Middleware Developer’s Guide for Oracle Entitlements Server 11g Release 1 (11.1.1) E14097-04, it is mentioned that need to have Policy Distribution Service defined in domains jps-config.xml.
“To use the PEP API, the identity store, the policy store, the Policy Distribution Service, and the user assertion login module must be defined in jps-config.xml.”
The question is:
Does the PEP API interface directly with the Policy Database or do I have to have the SM (security module) with Policy Distribution Service configured for my domain for the PEP call to work?
PS: The PEP API call is PepRequestFactoryImpl.getPepRequestFactory().newPepRequest(s,action,fullyQualifiedResource,applicationContext).decide(); and is always returning false although the subject has authorization.
Appreciate your help
Thanks
cp