Above is the high level diagram of OES architecture.
a) As we can see here, System Administrator sits on top. System Administrator communicates with administrative server (PAP). Admin server uses OES Management API (MAPI) for creating policies and identities. The PAP is also accessible programmatically using the OES Management API (MAPI).
b) Along with System Administrator, we also have Delegated Administrators. So if any delegation is required of any administration activities, then they can do the delegation. It will work similar to the System Administrator.
c) The Policy Administration Point (PAP) is the OES Administration Serverthat manages policies and the artifacts related to security.It is connected to other systems that are needed to work with policies:
- Identity store: Separately administered user store
- Policy store: Persistent storage of policies managed by OES
- Policy information points (PIP): Systems that can provide external attribute data used in OES policies
d) Next is our Security Modules(SM) which is also our Authorization Engine.
- An Security Module instance comprises the libraries and processes that are commonly referred to as an OES client.
- Depending on the type of SM instance, the authorization engine that is serving as the Policy Decision Point (PDP) is available in either of the following ways:
- Centrally via a networking port by an SM proxy
- Locally within the same JVM process, which is referred to as embedded
- The SM has direct access to the identity store the same way that the PAP does.
- Depending on the distribution model of the SM, it may or may not have direct access to the policy store. There are 2 types of Distribution Model.
- Non-Controlled and Controlled-Pull: The SM has direct access to the policy store, does not cache a copy of the policies locally, and keeps the policy model in memory. Policies are distributed directly either automatically by intervals or programmatically.
- Controlled-Push: The SM does not have a direct connection to the policy store. Policies are distributed manually from the PAP to the SM, which caches a copy of the policies locally on the file system in order to run if the OES Admin Server is not available, and keeps the policy model in memory.
- The authorization engine PDP is accessed by the application using the Policy Enforcement Point (PEP) API. This API is used to ask the PDP whether the user is authorized to take the requested action on a particular resource.
- The Application serves as the PEP, and uses the PEP API to call the PDP for an authorization decision. The PDP returns the outcome to the Application, which then enforces the decision made by the PDP.
So in simple words, the responsibility of System Administrator is to create the policies in policy store and create the identities in identity store. And System Administrator uses administrative server which internally uses Management API to create those identities and policies. Authorization engine comes into the picture at runtime where we have two security modules. The first one is the Central Policy Decision Point and the second one is Embedded Policy Decision Point which I will cover in my another blog. The authorization engine will interact with the Identity Store and it uses Runtime APIs to evaluate any rules and generate the outcome as Grant or Deny. Authorization engine, or the security module sitting inside authorization engine, also communicates with the Policy Information Point(PIP). This Policy Information Point contains all the information related to user attributes. So at runtime, whenever any request for policy relation will come, authorization engine will ask Policy Information Point to provide all the details related to user, and based on the details, it will generate the outcome as Grant or Deny.