The Impact of Oracle Entitlement Server (OES)

When customers are looking at deploying OES, or really an new piece of IT infrastructure, the question comes up "What is the cost to adopt this new thing?". Its sorta like a puppy...sure its cute and my kids love it and will love me for it, but who is gonna walk it, and clean-up after it, and when I go away I have to kennel it etc. So, this is the classic cost/benefit analysis that goes on every day inside of IT. Nothing new, but I just wanted to add some thoughts on the specifics of OES, its architecture and its impact on the organization.

The first question is "How are you going to deploy OES?". OES deploys in two ways - centralized and distributed. In the centralized model, you stand up a service, and applications talk to it over some protocol - SOAP or RMI. This has the advantage of having minimal application footprint (lightweight API), this can make adoption simpler, because you avoid the inevitable nastiness of getting a runtime loaded into foreign heterogeneous environment - i.e. classloading hell. The latency of making the authorization calls varies by protocol by its typically in the 10s of ms per call. This is not a lot, but if you have a webpage with 100 items and each call is 20 ms, people will notice the inclusion of OES. If this is the case, then using some of the child query APIs. This can eliminate multiple (read: chatty) API traffic. So, basically the centralized model has little impact on the infrastructure, but does requires some thinking and the software level.

The alternative is to deploy the Java SM/WLS SM into each application/container. This has the issue of maintaining and managing more software - think upgrade, but is very very very fast - latency below 1 ms. So, deploying embedded makes sense if you need the performance. Also, you can just call the API at will with out fear of the latency accumulating with multiple requests. Less impact of the software, more on the infrastructure.

Once you've figured out which model, and they are not mutually exclusive, you need to think about how to get OES integrated into application environments. In general, I don't see customers just writing whatever policies they want and calling them through the API. There needs to be some basic authorization model established and then implemented in OES. People do not typically put individual grants in OES admin console and then push out the changes - its simply not manageable. Instead, develop some policies that are data driven - example: Any customer can access any bank account they own (Good) vs. Josh can access bank account 12345 (Bad). Once the model is developed, wrapping the runtime API with a higher-level API that maps to the business domain model makes sense. In many cases, customers already have an existing model that OES is replacing, so this is a simple exercise. Just take the API that you have today - keep the interface, and replace the implementation will calls to OES. Then over time, extend the existing API to expose more of the functionality of OES.

Finally, who is going to own/operate OES. Typically, the development of the API/Policy is done by a development, business analysts and infosec working together. These policies once blessed are implemented, tested and deployed. Policies don't change that often, but the data that informs them does. OES has rich capabilities in the form of AttributeRetrievers to get information from a wide range of sources including LDAP, RDBMS, and custom. That information is managed there and then evaluated at runtime.

OES can be managed by application infrastructure or identity management teams. I've seen both. Typically, at the beginning of a deployment, it stays closed to the applications, since there is a lot of application context/dependencies. Over time as the model/deployment matures this function can move to the centralized IDM group.

Ultimately, OES is not that different from any other piece of middleware. How its deployed and managed at customer sights is not unique, but there are some subtleties that are listed above that are worth acknowledging and considering.