CON2381 Using ANSI Role-Based Access Control to Secure Java Enterprise Applications

1. CON2381 • Using ANSI Role-Based Access Control to Secure Java Enterprise Applications • Shawn McKinney, Principal, JoshuaTree Software • John Field, Solutions Architect, Pivotal 23 September 2013 11:30a JavaOne Hilton - Golden Gate 6/7/8 San Francisco CA

2. Agenda • RBAC intro • Common RBAC misconceptions • How to implement • Where to enforce • Demo Fortress RBAC • Wrap-up

3. INCITS 359 RBAC components • RBAC0: Core Users, Roles, Perms, Sessions • RBAC1: Hierarchical Roles • RBAC2: SSD Static Separation of Duties • RBAC3: DSD Dynamic Separation of Duties

4. Common RBAC Misconceptions

5. Common RBAC Misconceptions "A ROLE is just a 'group of users', à la Unix, right ?" False • A group is a collection of entities, which may be a user. • But a role is a many-to-many mapping between users and permissions.

6. Common RBAC Misconceptions "...Well then a role is just a collection of permissions?" False Again, a role is a many-to-many mapping between users and permissions.

7. Common RBAC Misconceptions "Our Java/JEE/Spring /LDAP ACL/Unix/DB checker can handle RBAC already" Perhaps… but only if it can do this: • Perform selective role activation in support of principle of least privilege during logon. • Perform updates and interrogations of user access to roles and permissions in real-time.

8. Common RBAC Misconceptions "It’s an academic model and will never work in the real world" False • RBAC in use for decades • Check out: http://csrc.nist.gov/groups/SNS/rbac/case_studies.html

9. Common RBAC Misconceptions "The whole point is to reduce the number of entitlements being managed by our security administrators" False • Common API and data model used for policy enforcement, administration and review functions. • Ensures best practices followed for regulatory compliance purposes. • Disparate apps plug into enterprise systems because they behave the same semantically. • Simplifies application security integration.

10. Common RBAC Misconceptions "Only works when user population performs the same repetitive job tasks and not good for complex jobs, i.e. knowledge-based workers" False • Roles may carry a set of rules governing when to assign and or activate. • Every application and system needs RBAC regardless of user type.

11. Common RBAC Misconceptions “Our application/work center uses over 100 Roles. Therefore RBAC isn’t helping anything." False • If you have over 100 Roles for a single application you did something wrong. • Take a look at how you define and enforce the security policy. Are you using the Role as if it were a Permission?

12. Common RBAC Misconceptions “RBAC doesn’t help enough with managing what our administrators do" True • You need a privileged identity management strategy for that. • There has not been a big push in this area. • Administrative Role-Based Access Control (ARBAC)

13. Common RBAC Misconceptions "... is not a Panacea" True • Will not be a cure for all past ills • Will provide a base upon which to build a successful IAM strategy going forward. • Will provide the tools in which to repair applications that use broken security models.

14. Common RBAC Misconceptions “Nothing’s going on there anymore. It’s obsolete" False • R&D ongoing in RBAC space • New standards, products, techniques being created. • RBAC Base Standard (ANSI 359-2011) update • RBAC Implementation and Interoperability (RIIS) – 2011 • RBAC Policy-Enhance Standard (RPE) – 494-2011

15. Common RBAC Misconceptions “Nobody’s been able to implement it yet because the spec is too complex." False • RBAC has been (largely) ignored by commercial IAM vendors, but not due to technical complexity. • RBAC has been working within infrastructure products (e.g. operating systems & databases) for years. • Now making a comeback in off-the-shelf IAM products… check out Fortress

16. Common RBAC Misconceptions Extra Credit

17. Common RBAC Misconceptions "We can't use it for fine-grained authorization" False • INCITS 359-2011 RBAC Base standard describes a many-to-many mapping between objects and operations which allows instance data to be mapped. • INCITS 494-2012 RBAC Policy Enhanced with attribute modifiers on permissions specifically to provide support for fine-grained authorization.

18. Common RBAC Misconceptions “Does not support attributes... so we use attribute-based access control instead." False • RBAC Base standard, 359-2011, updated to support more granular authorizations, i.e. support for attributes on permissions. • RBAC Policy-Enhanced Standard, 494-2011, provides support for dynamic constraints implemented in runtime.

19. Common RBAC Misconceptions (extra credit) “Role-Role Static SoD is just too simple to work. It only works at the role level and the toxic relationships are always between permissions." False • INCITS 494-2012 RBAC Policy Enhanced, section 5.4.2.2 Permission-permission (Static), specifically deals with this use case. • Or, use traditional INCITS 359 and use Static SoD in conjunction with Hierarchical Roles. Do not directly assign roles that have toxicity directly to Users.

20. How to Implement RBAC Engine Three steps to ANSI RBAC

21. How to Implement RBAC Engine Step 1 - Stack Choose a network and database stack

22. How to Implement RBAC Engine Step 2 - Design a simple RBAC data model • Follow ANSI INCITS 359 • Five basic elements • User - human or machine entity • Role - a job function within organization • Object - maps to system resources • Operation - executable image of pgm • Permission - approval to perform an Operation on one or more Objects

23. How to Implement RBAC Engine Step 3 - Design a simple RBAC software model • Follow ANSI INCITS 359 • Three standard interfaces • Administrative - CRUD • Review - policy interrogation • System - policy enforcement • Implementation may be swapped in future with another RBAC engine without impacting dependent applications

24. Fortress Demo • Users: • user1: assigned role_test1, role_test2, role_test3 • user2: assigned role_test2 • user3: assigned to role_test3 • Perms: • page1.button1: granted to role_test1 • page1.button2: granted to role_test1 • page1.button3: granted to role_test1 • page2.button1: granted to role_test2 • page2.button2: granted to role_test2 • page2.button3: granted to role_test2 • page3.button1: granted to role_test3 • page3.button2: granted to role_test3 • page3.button3: granted to role_test3 • Dynamic SoD: • Role Set: [role_test1, role_test2, role_test3] • cardinality = 2 (only two of three may activate) JVM Tomcat Fine Java EE Security (Tomcat Realm) Spring Page Security (Java EE Pre-authentication Filter) Wicket Buttons Fortress RBAC PEP Wicket Links Fortress RBAC PDP Wicket Base Page Granularity Apache Wicket Fortress RBAC Proxy Coarse

25. Fortress Demo Where to download http://iamfortress.org/WicketRbac

26. Where to Enforce John Field

27. RBAC Enforcements: Reference Model Candidate locations for RBAC enablement: SELinux JVM Geronimo Application Application Framework JEE Container JACC Provider Java Security Manager Platform Authentication Provider 1 2 OpenEJB (EJB) Tomcat (Servlet) Application Servlet Application SSB 3 App Framework App Framework 4 MAC & RBAC JACC JASPIC 5 MAC & RBAC Java SecurityManager 6 MAC & RBAC LSM Access Vector Table

28. Where to Enforce: (1) Application Offers maximum control, but not always feasible, and may not suffice. • Enables targeted, fine-grained controls in new applications. • Addition of RBAC to an existing app may imply refactoring. • Can be challenging if the original developers have departed. • Carries a potential risk of code tangling. • Mixing security enforcement code with app business logic. • Benefits of RBAC adoption are only incremental, per app. • Greatest ROI accrues when RBAC is adopted across the enterprise.

29. Where to Enforce: (2) Application Framework Enables broad adoption; Maintains appropriate Separation of Concerns • Good approach when the application already leverages an existing development framework, such as Wicket or Spring. • Application developers can focus on use cases, and stay out of the security enforcement business.

30. Where to Enforce: (2) Application Framework RBAC Enablement via Application Framework Beans • Wicket: • E.g., RBAC-aware page, link, button classes. • Spring Security: • RBAC-aware AccessDecisionManager, RoleVoter beans. • FilterChainProxy bean.

31. Where to Enforce: (3) JEE Container Fortress Java Sentry provider for Tomcat Realm • Tomcat Realmdefines the provider interface from the container managed PEP, to a back-end PDP. • E.g. implements interface org.apache.catalina.Realm • E.g., JDBC database, JNDI directory, or another custom provider. • Fortress Java Sentry provides an RBAC Realm • For both Tomcat 6, and 7. • True RBAC compliance for any application deployed with container-managed security.

32. RBAC Enforcement via Tomcat Realm Configuring Fortress Java Sentry in /conf/server.xml <Engine name="Catalina" defaultHost="localhost”> <!--Fortress Sentry Realm Configuration --> <Realm className="us.jts.sentry.tomcat.Tc7AccessMgrProxy" debug="0" resourceName="UserDatabase" containerType="Tomcat7" realmClasspath="/opt/pivotal/fortress/sentry-1.0-RC29/conf: /opt/pivotal/fortress/sentry-1.0-RC29/dist/fortressSentry-1.0-RC29.jar"/> … </Engine>

33. Where to Enforce: (3) JEE Container Secure the deployment infrastructure, rather than individual apps. • Enables enterprise security architect to drive uniform adoption, and maximize the ROI. • Ensures consistent service levels across applications; avoids redundancy. • Improves Data Center operational processes • Including System Managers, Audit and Regulatory Compliance.

34. Where to Enforce: (4) JACC Provider A standards-compliant approach for heterogeneous infrastructures. • JSR-115 defines the JACC standard • Java Authorization Contract for Containers. • Defines a standard security SPI to plug into JEE container. • Covers both the deployment-time contract, and run-time contract. • Goal: interoperability of provider across different containers. • E.g., WLS, WAS, Geronimo, etc. • Unifies enforcement semantics for Java EE and Java SE.

35. RBAC Enforcement via an Existing JACC AOP advice enables injection of true RBAC into any compliant provider. • What if we can’t replace the existing JACC provider? • Use Aspect Oriented Programming w/Load-Time Weaving to supplement existing JACC provider with Advice. • Intercept the Policy.implies(protectionDomain, permission) method at runtime, and add supplementary RBAC check. • If not RBAC, we allow the existing JACC implementation handle the request.

36. RBAC Enforcements: Reference Model Candidate locations for RBAC enablement: SELinux JVM Geronimo Application Application Framework JEE Container JACC Provider Java Security Manager Platform Authentication Provider 1 2 OpenEJB (EJB) Tomcat (Servlet) Application Servlet Application SSB 3 App Framework App Framework 4 MAC & RBAC JACC JASPIC 5 MAC & RBAC Java SecurityManager 6 MAC & RBAC LSM Access Vector Table

37. Pivotal POC Implementation SELinux JVM Geronimo Authentication Provider OpenEJB (EJB) Tomcat (Servlet) Application Servlet Application SSB App Framework App Framework MAC & RBAC JACC JASPIC MAC & RBAC Java SecurityManager MAC & RBAC LSM Access Vector Table

38. POC Implementation JVM Geronimo PSI-Impl Fortress RBAC PDP OpenEJB (EJB) Tomcat (Servlet) Application Servlet Application SSB PSI-PEP App Framework App Framework • PSI: Pivotal Security Interceptor • PSI-PEP: Policy Enforcement Point • AOP Advice on App Framework • PSI-Proxy: AOP Advice on JACC • PSI-Impl: Uses Fortress client MAC & RBAC PSI-Proxy JACC MAC & RBAC Java SecurityManager

39. RBAC Enforcement via JACC Defining the AOP Advice pointcutonPolicyImplies(ProtectionDomainpd, Permission fcp): call (public booleanPolicy+.implies(ProtectionDomain, Permission)) && args(pd, fcp); booleanaround(ProtectionDomainpd, Permission fcp) : onPolicyImplies(pd, fcp) { result= proceed(pd, fcp); … if ((!result) && permissionType.equals(”RBAC”)) { result= fortress.checkAccess(resource, operation, principal); } returnresult; }

40. RBAC Enforcement via JACC Configuring the AOP Advice <aspectj> <aspects> <aspect name="com.gopivotal.security.pep.Jacc.advice"/> </aspects> <weaver options="-verbose -showWeaveInfo"/> </aspectj>

41. Where to Enforce: (5) Java SecurityManager Unified interface enables JACC providers to enforce at the JVM level • A compliant JACC provider may delegate any out-of-scope request to the existing JVM SecurityManager, if any. • A compliant JACC provider may also be configured as a Java SE SecurityManager.

42. Where to Enforce: (6) Platform RBAC enablement, even for privileged users and processes • Assurance is only as good as the underlying platform. • Use of RBAC with facilities such as SE Linux can provide a technical enforcement mechanism for privileged users. • E.g. SOD for deployment engineers, system operators, and DBAs. • Centralized policy store, rather than per-machine policy management and audit.

43. Summary • Enterprise applications can use real RBAC now! • There is always more than one way to do it. • 80/20 Rule: • Choose container-based enforcement + any other. • Solid Open Source implementation available today.

44. Come to the BOF “Open Source Identity Access Management Expert Panel” • BOF 2337 • Hilton – Golden Gate 6/7/8/ • Today @ 5:30 PM

45. Where to find out more about the RBAC standard • http://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf • http://csrc.nist.gov/groups/SNS/rbac/ • http://www.wisegateit.com/resources/downloads-rbac • https://blogs.oracle.com/identitythink/entry/whats_wrong_with_the_nist_rbac

46. Where to find out more about Fortress RBAC implementation • http://iamfortress.org/ • http://iamfortress.org/WicketRbac