Securing data instances with ERBAC


Published on

Security systems have traditionally had a high level of support for Role-Based Access Control (RBAC) but typically fail at providing more than programmatic checks for instance-level access control. Come and see how Entity-Relationship Based Access Control (ERBAC) allows you to declaratively secure instances of data by using their association with the currently executing subject. Kalle Korhonen will be presenting an overview of several add-on modules he's built on top of Apache Shiro to provide comprehensive security framework for modern web applications using Apache Tapestry 5 and JPA.

Published in: Technology, Lifestyle
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Securing data instances with ERBAC

  1. 1. Securing data instances with ERBAC Kalle - Apache Tapestry - Apache Shiro
  2. 2. Me and open source• Founder of • a full web stack suite for Tapestry 5 • successor to Trails Framework, one of the original Ruby on Rails wannabes for Java• Committer to Apache Tapestry, Apache Shiro - Apache Tapestry - Apache Shiro
  3. 3.• Some stats : • 5 active committers, 13 all time • similar in size with Apache Shiro • 22 individual modules + sub modules• tapestry-model the bread and butter: the most customizable CRUD framework for Java• recently more JPA modules - Apache Tapestry - Apache Shiro
  4. 4. Security related modules• tapestry-security, Apache Shiro integration for Tapestry 5• tynamo-federatedaccounts, account federation with remote authentication providers (Facebook, Twitter, Google, LDAP, etc.)• tapestry-editablecontent, poor mans CMS, currently JPA only• - tynamo-federatedaccounts- rollingtokens, rememberme authentication based on rolling tokens - Apache Tapestry - Apache Shiro
  5. 5. tapestry-editablecontent - Apache Tapestry - Apache Shiro
  6. 6. tynamo-federatedaccounts• Oauth: Facebook, Twitter, ...• OpenID• Not protocol specificpublic static void bind(ServiceBinder binder) { binder.bind(FederatedAccountService.class,DefaultHibernateFederatedAccountServiceImpl.class);}public static void contributeFederatedAccountService(MappedConfiguration<String,Object> configuration) { configuration.add("*", User.class); configuration.add("", "facebookId");}public static void contributeApplicationDefaults(MappedConfiguration<String,String> configuration) { configuration.add(FacebookRealm.FACEBOOK_CLIENTID, "<client id>"); configuration.add(FacebookRealm.FACEBOOK_CLIENTSECRET, "<client secret>");} - Apache Tapestry - Apache Shiro
  7. 7. tapestry-security• started out as a thin layer• replaced (Ini)ShiroFilter• replaced ini configuration with Tapestrys all-in-java contributions• replaced shiros built-in filters with our own base classes• proving ground for new stuff (e.g. logical operator first existed in tapestry-security) - Apache Tapestry - Apache Shiro
  8. 8. Security check points• secure views (url-based, annotations)• secure method invocations (role- type)• secure data - how?• how do I declare that user can only edit his profile? - Apache Tapestry - Apache Shiro
  9. 9. Current approach..@Overrideprotected AuthorizationInfodoGetAuthorizationInfo(PrincipalCollection principals) { SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(); info.addStringPermission("account:update:1");}// page template...<t:security.haspermission permission="editEntityPermission">...</t:security>// page class (controller)public String getEditEntityPermission() { return "account:edit:" + entityId;} - Apache Tapestry - Apache Shiro
  10. 10. What if you could just do..@Entity@RequiresAssociation(value = "owner", operations =Operation.UPDATE)public class Account { @OneToOne private User owner;} - Apache Tapestry - Apache Shiro
  11. 11. ERBAC• Entity-Relationship Based Access Control• Initial concept 5 years ago with Hibernate !• find out how the data is associated with the currently executing subject• secure entities with annotations• role-based security is easy• allow limiting scope to a specific CRUD operation (CREATE, READ, UPDATE, DELETE) - Apache Tapestry - Apache Shiro
  12. 12. EntityManager operations• SecureEntityManager used automatically when Subject is bound• find -> READ (separate service for lists)• merge (INSERT if doesnt exist)• persist (update -> remove + insert)• remove• create*query() operations are unprotected• takes care of 80% of instance security needs - Apache Tapestry - Apache Shiro
  13. 13. What next?• same model would work for Hibernate, JDO..• push to Shiro?• at least annotations ... anything more is difficult because Shiro is persistence agnostic - Apache Tapestry - Apache Shiro
  14. 14. Thank you!For more information, visit : do You think? - Apache Tapestry - Apache Shiro