OES11g WebLogic SM is special in a couple of ways. People are often confused about how it works. Oracle Entitlements Server WebLogic SM is closely related to how WebLogic’s security works. In this blog post, I will look at WebLogic’s security and then see how Oracle Entitlements Server integrates with it.
First some definitions:
- PDP (Policy Decision Point): PDP is where authorization decisions are made. You can think of PDP as judiciary (court system). A judge can say if there was a violation of law (in our case authorization policies). But a judge cannot enforce. For example, a judge can issue an arrest warrant but the judge cannot physically arrest the offender.
- Oracle Entitlements Server PDP (Policy Decision Point): This is the core authorization engine within Oracle Entitlements Server. Sometimes this is also called as Java-SM, because Java-SM is pretty much the same as the core authorization engine/PDP
- PEP (Policy Enforcement Point): This module is responsible for enforcing authorization decisions. PEP cannot make any decisions. PEP is similar to police force. For example, a police office cannot pass judgments about what is right/wrong but he/she can take appropriate actions for enforcement.
- Container Managed Objects: These are JEE objects which are managed and secured by container. For example, URLs, EJBs, JMS queues etc. For example, to contrast, POJOs are not JEE objects and they are not directly managed by container.
- OPSS (Oracle Platform Security Service): This is a common security framework used by several Oracle products including Identity Management (IDM), SOA, FMW and FA.
- OPSS-CSS: This is a flavor of OPSS which is designed to work with BEA products. As you know, BEA was acquired by Oracle.
Overview of WebLogic Security
To keep things simple, let us start our discussion with a vanilla WebLogic (WLS) server, which does not have any Oracle Entitlements Server.
Authentication and Authorization in WebLogic
These steps correspond to a user (web browser) accessing a secured page for the first time. This means user needs to be authenticated. Steps below correspond to figure 1
- Web browser tries accessing a protected page
- WebLogic notices that this is a first access to the application and forces an authentication. This step might involve a redirect to login page, but we will keep things simple here. In this diagram, WebLogic calls into OPSS-CSS framework to authenticate the user
- OPSS-CSS framework calls into identity asserters (or authentication modules)
- Identity asserter establishes user’s identity and passes the identity information to OPSS-CSS framework
- OPSS-CSS framework then passes the authenticated identity (typically as a JAAS subject) back to the WLS container
- Next WLS container calls into OPSS-CSS framework for authorization on the page. This is to make sure that the authenticated user is indeed authorized to view the web page
- OPSS-CSS framework calls into WLS OOTB authorization provider
- WLS OOTB authorization provider verifies authorization and sends a response (permit/deny) back to the OPSS-CSS framework. Strictly speaking an authorization provider can return a permit, deny or abstain. For this blog post, I will ignore abstain. Some time later, I will write an article about how abstain is used.
- OPSS-CSS framework then sends the response (permit/deny)back to the WLS container
- If the user is not authorized to view the page, WLS aborts the request by sending an “authorization denied” error message to the browser. If the user is authorized to view the page, the container forwards the request to the Web Application.
- The web application processes the request and sends a response back to the container. Generally this response is in the form of raw HTML content
- The container then sends a response back to the web browser. Generally this response is a properly rendered HTML page.
Figure 1
Although the above flow might look complicated, in reality it is pretty simple. The flow is structured to be highly flexible. Even after working in this space for six years, I continue to be amazed at the flexibility offered by OPSS-CSS framework.
Authorization in WebLogic
Once a user is authenticated the flow looks a little simpler (remember that we still do not have Oracle Entitlements Server). Steps below correspond to figure 2.
- Web browser (user) requests another page
- WLS container examines the browser’s cookie and determines that the user was previously authenticated. It retrieves the user’s authenticated identity from its internal cache. Then the container uses the authenticated identity and makes an authorization request for the web page.
- OPSS-CSS framework makes the corresponding authorization call to WLS OOTB authorization provider
- The authorization provider sends the authorization decision(permit/deny) back to OPSS-CSS framework
- OPSS-CSS framework sends the the final authorization decision(permit/deny) back to the container
- If the user is authorized to view the page, the container tries to fetch the page from the web application
- The web application sends a response back to the WLS container
- Finally the container sends a response back to the calling application
Figure 2
As you can see, once a user is authenticated (i.e. user’s identity is established), Identity Asserter is not used. In the following diagrams we will leave out the Identity Asserter.
How Oracle Entitlements Server WebLogic SM works
Now, let us introduce Oracle Entitlements Server and see how it impacts the flow. There are two options for setting up Oracle Entitlements Server on WLS. Let us call them API and Interceptor modes. In the API mode, applications make explicit PEP API authorization calls to get an authorization decision from OES PDP. In the interceptor mode OES hooks itself into the container’s security and is invoked automatically by the container. This hook is called “OES Authorization Proxy”
OES WebLogic SM in API Mode
When you configure OES WLS SM, by default it is setup in API mode. So let us look at the flow in API mode. We will assume that the user was previously authenticated. Steps below correspond to figure 3.
- Web browser (user) requests another web page
- WLS container examines browser’s cookie and knows the user was previously authenticated. It retrieves the user’s authenticated identity from cache. Then, the container uses the authenticated identity and makes an authorization request for the web page.
- OPSS-CSS makes the corresponding call to WLS OOTB authorization provider
- The authorization provider sends the response (permit/deny)back to OPSS-CSS framework
- OPSS-CSS framework sends the the authorization decision(permit/deny) back to the container
- Then the container tries to fetch the page from the web application
- Next the web application makes an authorization request with the OES PDP using PEP API (i.e. OES runtime authorization API). As you can see, this request directly goes to OES PDP and WLS container is not involved in this flow.
- OES PDP computes the authorization decision and sends the response back to the application
- The application can optionally make additional authorization requests with OES PDP.
- OES PDP will send back the authorization response
- Application returns the results to the container
- WLS container sends the response back to the web browser
Figure 3
As you can see above, web application directly invokes authorization calls with OES. So container is not directly involved.
OES WebLogic SM in Interceptor Mode
Next, let us look at the flow when OES is used as an interceptor. In this mode OES registers itself with OPSS-CSS framework as a container security provider. I will create a future blog post about how to register OES as an interceptor, in the mean time refer to the official OES product docs or request help from Oracle support. Steps below correspond to figure 4.
- Web browser (user) requests another web page
- WLS container examines Browser Cookie and knows the user was previously authenticated. It retrieves the user’s authenticated identity from cache. Then, the container uses the authenticated identity and makes an authorization request for the web page.
- OPSS-CSS makes the corresponding call to WLS OOTB authorization provider
- The authorization provider sends the response (permit/deny)back to OPSS-CSS framework
- OPSS-CSS framework then calls into the OES Authorization Proxy
- OES Authorization Proxy forwards the authorization request to OES PDP
- OES PDP computes the authorization decision (permit/deny) and sends back the response
- OES Authorization Proxy sends the response (permit/deny) back to OPSS-CSS framework
- OPSS-CSS framework combines the individual authorization results (permit/deny) from WebLogic Authorization Provider and OES Authorization Proxy and sends the final response (permit/deny) to the WLS container. As you might have guessed, some times it is difficult to merge individual permit/deny authorization responses into a single-final permit/deny. I will talk about how this is done in another blog post
- The container requests the web page from the web application
- The application returns the web page to the container
- The container sends the response to the web browser
Figure 4
There are different tradeoffs between these two approaches. My recommendations are:
Use API mode when:
- You do not want to change security realm settings for the WLS container. Remember, that security realm settings are shared across WLS cluster. So changing the setting on one node can potentially impact your entire farm.
- In the Interceptor mode, WLS automatically maps URLs into OES objects. If you are not happy with the default mapping, you can write a servlet interceptor and perform authorization checks using OES API.
- API gives you a lot of flexibility in how you can construct the authorization request.
- Interceptor mode cannot secure regular POJOs and non-JEE objects. This is because WLS only manages authorization for JEE objects.
Use Interceptor mode when:
- You want to secure JEE artifacts such as URLs, EJBs, JMS queues etc.
- Application code cannot be modified to make OES API calls
- Generally setting up interceptor mode is easier because all you need to do is change configuration.
OES WebLogic SM Combining API and Interceptor Modes
You can use these two modes in combination to get the best of both worlds. Figure below shows the flow. As you can see it is a combination of figures 3 and 4.
Figure 5
Great article !!! Can you please send me documentation related to this ?
Hi Samita,
Thanks very much! You can find the official OES document here and WLS documents here. In this article I consolidated information from both of these docs to simplify the underlying concepts.
Bye,
Subbu
when I am developing an application in Jdeveloper for step 7 in figure 3 what configuration will be required on the Integrated Domain ? My understanding is that all the diagrams are representing calls made to a weblogic domain acting as a SM right ?
Hi Subbu,
I referred the OES Document link you mentioned in the blog to make Weblogic SM work in interceptor mode. i made the changes as mentioned. But it seems, it is still not working. I am able to see the response in AuthzResponse.jsp page in the sample vanilla application of your demo. So what could be the problem?
Regards,
Piyush
Hi Piyush,
Unfortunately, I have not personally tried this procedure. Can you open an Oracle SR and ask help from the support team.
Thanks,
Subbu
Hi Subbu,
Should OES really reside in the same weblogic container as that of my application.
What if i have my application in a different weblogic container (different middleware home)? Will i able to OES enforce restriction on a different weblogic container?
Regards,
J