The Case for a Policy Decision Point inside the LDAP Server
WHY ON EARTH WOULD YOU DO THAT?
We all understand that runtime characteristics change as processes get moved around the network. Having problems with network io? Move the database daemon to the same tier as the client process. Worried about file io? Store the data in memory as opposed to disk. etc…
These same notions apply for system architecture with respect to security. Location of policy enforcement, decision, and database processes hugely impact the overall welfare of your organization’s computational systems.
With these kinds of thoughts, let’s move the security processes around and see what happens.
But first, we’ll define them:
1. POLICY ENFORCEMENT POINT (PEP)
Invoked by client programs for security policy enforcement. These gatekeepers are embedded directly into their host thus require platform specific bindings. The less impact to their host, the better.
2. DATABASE (DB)
Invoked by PDPs to store security credentials, attributes and activity logs. An important concern is speed; to be used correctly, it’s used often. Another important concern is reliability; the integrity of its data is mission critical.
3. POLICY DECISION POINT (PDP)
Invoked by PEPs and dependent on a DB. Responsible for computing:
authentication – with passwords or keys
authorization – with attributes or permissions
audit trail – identify subjects, decisions, time/date/locations, and resources
THREE TYPES OF PDPS
Type 1 – runs in-process to PEP, with out-of-process DB
Type 2 – runs out-of-process to PEP, with out-of-process DB
Type 3 – runs out-of-process to PEP, with in-process DB
PDP TYPE 1 (RUNS IN-PROCESS TO PEP)
The Tomcat JDBC Realm is a Type 1 PDP. It functions both as PEP and PDP. Other Type 1’s include Apache Fortress, Shiro and Spring Security. Most of the open-source security frameworks are this type. The policy decisions happen synchronously inside the client process.
TYPE 1 PDP INTERACTION BETWEEN PROCESSES
BENEFITS OF TYPE 1 PDP
TYPE 1 PDP ADVANTAGES
simple – only security framework and DB required
works well for single deployments of stand-alone apps
TYPE 1 PDP DISADVANTAGES
more code exposed to the client (making deployment harder)
more load on the client
more memory consumed on the client
more network io traffic on the client
fewer platforms supported (can it run on Java, NET, PHP, Python, and all the others?)
PDP TYPE 2 (RUNS OUT-OF-PROCESS TO PEP AND DB)
Here the PDP and DB both run out-of-process to the PEP. These types of PDPs are more complicated and usually obtained as separate COTS or OSS products. For example, CA Siteminder, Tivoli Access Manager, Oracle Access Manager, Shibboleth, CAS and many others.
TYPE 2 PDP INTERACTION BETWEEN PROCESSES
BENEFITS OF TYPE 2 PDP
TYPE 2 PDP ADVANTAGES
less network traffic on client
less cpu consumed on client
less memory consumed on client
less code exposed to client (making deployment simpler)
more platforms supported (simple to code PEP ‘shims’ to communicate with centralized PDPs)
TYPE 2 PDP DISADVANTAGES
more security processes to maintain due to PEP, PDP and DB all running separately (increasing management burden)
poor response time due to extra network hops
poor throughput due to PDP reliance on heavyweight communication protocols (xml/json/http)
PDP TYPE 3 (RUNS OUT-OF-PROCESS TO PEP AND IN-PROCESS TO DB)
The PDP and DB run in-process and the PEP is out-of-process. The advantage here is offloading computations from the PEP reducing load and traffic from the client. It gains speed over the Type 2 because of the embedded database.
TYPE 3 PDP INTERACTION BETWEEN PROCESSES
BENEFITS OF TYPE 3 PDP
TYPE 3 PDP ADVANTAGES
all of Type 2
embedded database speed gain
embedded database reliability gain
TYPE 3 PDP DISADVANTAGES
poor throughput due to reliance on heavyweight communication protocols (xml/json/http)
THE CASE FOR A PDP IN OPENLDAP
The Enforcement Foundry RBAC Accelerator is a Type 3 PDP. It has all the advantages of its type without the disadvantage because using extended LDAP protocols is very efficient. It runs inside of the OpenLDAP slapd daemon and uses LMDB, which is the fastest embedded, key-value database available, giving a nice turbo boost to read/write speeds.
Now let’s return to the original question: Why on earth would you do that?
To enable authentication, fine-grained authorization, and audit trail on every platform. To ease concerns for high cpu, memory, network, and file io consumption. And to use well understood technologies that can be widely distributed.
Just how good is that performance? Read about it here: