Introducing a Security Access Control Engine Inside OpenLDAP The OpenLDAP RBAC Accelerator May 13, 2016 ApacheCon NA, Vancouver This Session’s Objectives • Convince you that having a Policy Decision Point (PDP) inside an LDAP server is a good idea. • Focus on the idea rather than a product. ApacheCon NA, Vancouver 2016 2 Introductions Shawn McKinney • Software Architect • PMC Apache Directory Project • Engineering Team ApacheCon NA, Vancouver 2016 3 Agenda • Idea & Rationale • Specs & Requirements • Implementation • Standardization • Demo IMAGE FROM: HTTP://EVENTS.LINUXFOUNDATION.ORG/EVENTS/APACHECON-NORTH-AMERICA ApacheCon NA, Vancouver 2016 4 Hit a Wall with Policy Enforcement Need a Policy Decision Point implementation for every platform. We wanted one of these that runs natively… and had to build a PDP as well. OpenLDAP LM ApacheCon NA, Vancouver 2016 5 Started With An Idea • Proposed by Ted Cheng in 2012 • Move the PDP into the LDAP server • Utilize the natural strengths of LDAP protocol Image from: http://www.clker.com/clipart-6937.html • Simpler client-side bindings OpenLDAP LM 6 Rationale Because you’re unconvinced. http://affordablehousinginstitute.org/blogs/us/2013/09/city-of-mirag es-part-8-can-this-roa d-make-sense.ht ml ApacheCon NA, Vancouver 2016 7 But First A quick look at access control system composition… ApacheCon NA, Vancouver 2016 8 Access Control System Composition 1. Policy Enforcement Point (PEP) 2. Policy Decision Point (PDP) 3. Database (DB) ApacheCon NA, Vancouver 2016 9 Policy Enforcement Point • Invoked by the apps for security checks. • TheThe SecuritySecurity System’sSystem’s Gatekeeper.Gatekeeper. • Requires platform specific bindings. • Best to reduce impact to the host machine. ApacheCon NA, Vancouver 2016 10 Database • Invoked by PDPs to store security stuff. • TheThe SecuritySecurity System’sSystem’s LongLong--termterm Memory.Memory. • Must be reliable, consistent and fast. ApacheCon NA, Vancouver 2016 11 Policy Decision Point • Invoked by PEP and dependent on the DB. • TheThe SecuritySecurity System’sSystem’s Brain.Brain. • Authenticates with passwords and keys. • Authorizes using attributes and permissions. • Audit trail. ApacheCon NA, Vancouver 2016 12 Three Composition Types • Type 1 – PDP runs in-process to PEP, with out- of-process DB • Type 2 – PDP runs out-of-process to PEP, with out-of-process DB • Type 3 – PDP runs out-of-process to PEP, with in-process DB ApacheCon NA, Vancouver 2016 13 Type 1 Process Communication • PEP and PDP on one tier • DB on another ApacheCon NA, Vancouver 2016 14 More on Type 1 Composition • The PEP and PDP run in-process and the DB is out-of- process. • Policy decisions occur synchronously inside the client process. • Combines the PEP and PDP into a single component. • Most open-source security frameworks are this type. – Tomcat JDBC Realm – Apache Fortress – Spring Security – Apache Shiro ApacheCon NA, Vancouver 2016 15 Pros/Cons of Type 1 Advantages Disadvantages • Simple – only security • More code exposed to the framework and DB required client (making deployment • Widely available harder) • Works well for single • More load on the client deployments of stand-alone • More memory consumed apps on the client • Many options for database • More network io traffic on usage. the client • Fewer platforms supported ApacheCon NA, Vancouver 2016 16 Type 2 Process Communication • All on separate tiers ApacheCon NA, Vancouver 2016 17 More on Type 2 Composition • The PEP, PDP and DB all run out-of-process from one another. • More complex than a Type 1 PDP. • Obtained as separate COTS – CA Siteminder, Tivoli Access Manager, Oracle Access Manager • Or OSS products: – OpenAM, Shibboleth, and CAS ApacheCon NA, Vancouver 2016 18 Pros/Cons of Type 2 Advantages Disadvantages • Less network traffic on client • More security processes to maintain due to PEP, PDP and DB • Less cpu consumed on client all running separately (increasing • Less memory consumed on management burden) client • Poor response time due to extra network hops • Less code exposed to client • Poor throughput due to PDP (making deployment simpler) reliance on heavyweight • More platforms supported communication protocols xml/json over http. ApacheCon NA, Vancouver 2016 19 Type 3 Process Communication • PEP on one tier • PDP and DB on another ApacheCon NA, Vancouver 2016 20 More on Type 3 Composition • The PDP and DB run in-process and the PEP is out-of-process. • Not widely available today. ApacheCon NA, Vancouver 2016 21 Pros/Cons of Type 3 Advantages Disadvantages • All of Type 2’s • Fewer options for database • Embedded database speed usage gain • Poor throughput due to • Embedded database reliance on heavyweight reliability gain communication protocols xml/json over http. ApacheCon NA, Vancouver 2016 22 What is LDAP ApacheCon NA, Vancouver 2016 23 Benefits of LDAP • Standards-based (portable) • Compact and efficient wire protocol (fast) • Supports robust replication and high availability requirements (safe) • Rich data model (good) • Relatively easy to code (cheap) ApacheCon NA, Vancouver 2016 24 Pros/Cons of Type 3 with LDAP Advantages Disadvantages • All of Type 3’s • Less options for database usage • Poor throughput due to reliance on heavyweight communication protocols (xml/json/http) ApacheCon NA, Vancouver 2016 25 Specs & Requirements Because you’re still not convinced. Image from: http://www.cockpitseeker.com/aircraft/ ApacheCon NA, Vancouver 2016 26 System Requirements • Policy Enforcement APIs – Works on multiple platforms • Authentication – Works within various protocols, i.e. SAML, OpenID Connect • Authorization – Fine-grained and standards-based • Audit Trail – Centralized and queryable • Administration – Covered by Apache Fortress • Service-based SLA – Security, performance, and reliability ApacheCon NA, Vancouver 2016 27 Other Requirements • Lockout Procedures based on Time & Date • Session persistence and replication • Password policies • Multitenancy ApacheCon NA, Vancouver 2016 28 Audit • System • Principal Identity Compliance • Date Assurance • Resource • Resource Identity • Operation Objectivity • Result ApacheCon NA, Vancouver 2016 29 Temporal Constraints Applies to User and Role • Time of Day activations • Day of Week • Begin and End Date • Lockout Periods 30 Persistent or Transient Session? Each has its own benefits… Transient Persistent 1. Less processing on server 1. Less data to transfer over 2. Less data stored wire 3. More flexibility in terms of 2. Less processing on client attributes managed 3. Supports session timeout and concurrency controls ApacheCon NA, Vancouver 2016 31 Non-Functional Requirements • Fault Tolerant Business • Highly Available Requirements • Highly Performant User Requirements System Requirements ApacheCon NA, Vancouver 2016 32 Non-Functional Requirements • Optimized for Performance • Low latency – < 1ms • High throughput – > 100,000 TPS http://americandigest.org/sidelines/2010/04/flying_the_blac.html ApacheCon NA, Vancouver 2016 33 ApacheCon NA, Vancouver 2016 34 Which Functional Specifications • Role-Based Access Control - ANSI INCITS 359 • IETF Password Policies (draft) ApacheCon NA, Vancouver 2016 35 ApacheCon NA, Vancouver 2016 36 Role-Based Access Control (RBAC) • RBAC0RBAC0 --– Users,Users, Roles, Roles, Perms, Perms, Sessions Sessions Support this one • RBAC1 – Hierarchical Roles • RBAC2 – Static Separation of Duties (SSD) • RBAC3 – Dynamic Separation of Duties (DSD) ANSI INCITS 359 http://csrc.nist.gov/groups/SNS/rbac/ ApacheCon NA, Vancouver 2016 37 Functional Specifications LDAPCon, Edinburgh 2015 38 Three Interfaces of RBAC These are covered by 1. Administrative – CRUD Apache Fortress 2. Review – policy interrogation The new PDP 3. SystemSystem –– policypolicy enforcementenforcement will implement this one ApacheCon NA, Vancouver 2016 39 RBAC System Interface public interface AccelMgr { Link to AccelMgr javadoc Session createSession( User user, boolean isTrusted ); List<Permission> sessionPermissions( Session session ); List<UserRole> sessionRoles( Session session ); OpenLDAP void addActiveRole( Session session, UserRole role ); AccelMgr APIs void dropActiveRole( Session session, UserRole role ); User getUser( Session session ); map to the INCITS boolean checkAccess( Session session, Permission perm); 359 specs } http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git Link to INCITS 359 spec API Usages – Check Access User Permission Check: booleanboolean checkAccess(Session checkAccess( session, Permission perm) Session sess,Permission perm) Perform user RBAC authorization. This function returns a Boolean value meaning whether the subject of a given session is allowed or not to perform a given operation on a given object. The function is valid if and only if the session is a valid Fortress session, the object is a member of the OBJS data set, and the operation is a member of the OPS data set. ApacheCon NA, Vancouver 2016 41 RBAC Demo JavaOne, San Francisco 2015 RBAC Demo https://github.com/shawnmckinney/ role-engineering-sample ApacheCon NA, Vancouver 2016 43 RBAC Demo • Two pages • Each has buttons controlled by RBAC Permissions. • One Role per page. User to Role Buyers Page Sellers Page ssmith True False jtaylor False True Johndoe* True True * DSD constraint limits user from activating both roles simultaneously. JavaOne, San Francisco 2015 44 RBAC Demo Buyer Seller Both Permission ssmith rtaylor johndoe* 1 Item.bid True False True 2 Item.purchase True False True 3 Item.ship False True True 4 Item.search True True True