Feature image from: http://kb.linuxvirtualserver.org/wiki/Building_Scalable_Network_Services

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
• widely available
• 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 OpenLDAP 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.