Securing data instances with ERBAC

  • Upload
    kaosko

  • View
    924

  • Download
    0

Embed Size (px)

DESCRIPTION

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.

Citation preview

  • 1. Securing data instances with ERBACKalle Korhonentynamo.org - Apache Tapestry - Apache Shiro

2. Me and open source Founder of Tynamo.org 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 Shirotynamo.org - Apache Tapestry - Apache Shiro 3. Tynamo.org Some stats : 5 active committers, 13 all time similar in size with Apache Shiro 22 individual modules + sub modules tapestry-model the bread andbutter: the most customizableCRUD framework for Java recently more JPA modules tynamo.org - Apache Tapestry - Apache Shiro 4. Security related modules tapestry-security, Apache Shirointegration for Tapestry 5 tynamo-federatedaccounts, accountfederation with remote authenticationproviders (Facebook, Twitter, Google,LDAP, etc.) tapestry-editablecontent, poor mansCMS, currently JPA only - tynamo-federatedaccounts-rollingtokens, remembermeauthentication based on rolling tokenstynamo.org - Apache Tapestry - Apache Shiro 5. tapestry-editablecontent tynamo.org - Apache Tapestry - Apache Shiro 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 configuration) {configuration.add("*", User.class);configuration.add("facebook.id", "facebookId");}public static void contributeApplicationDefaults(MappedConfiguration configuration) {configuration.add(FacebookRealm.FACEBOOK_CLIENTID, "");configuration.add(FacebookRealm.FACEBOOK_CLIENTSECRET, "");} tynamo.org - Apache Tapestry - Apache Shiro 7. tapestry-security started out as a thin layer replaced (Ini)ShiroFilter replaced ini configuration withTapestrys all-in-java contributions replaced shiros built-in filters withour own base classes proving ground for new stuff (e.g.logical operator first existed intapestry-security)tynamo.org - Apache Tapestry - Apache Shiro 8. Security check points secure views (url-based,annotations) secure method invocations (role-type) secure data - how? how do I declare that user can onlyedit his profile? tynamo.org - Apache Tapestry - Apache Shiro 9. Current approach..@Overrideprotected AuthorizationInfodoGetAuthorizationInfo(PrincipalCollection principals) {SimpleAuthorizationInfo info = new SimpleAuthorizationInfo();info.addStringPermission("account:update:1");}// page template......// page class (controller)public String getEditEntityPermission() {return "account:edit:" + entityId;} tynamo.org - Apache Tapestry - Apache Shiro 10. What if you could just do..@Entity@RequiresAssociation(value = "owner", operations =Operation.UPDATE)public class Account {@OneToOneprivate User owner;}tynamo.org - Apache Tapestry - Apache Shiro 11. ERBAC Entity-Relationship Based AccessControl Initial concept 5 years ago withHibernate ! find out how the data is associatedwith the currently executing subject secure entities with annotations role-based security is easy allow limiting scope to a specificCRUD operation (CREATE, READ,UPDATE, DELETE)tynamo.org - Apache Tapestry - Apache Shiro 12. EntityManager operations SecureEntityManager usedautomatically when Subject is bound find -> READ (separate service forlists) merge (INSERT if doesnt exist) persist (update -> remove + insert) remove create*query() operations areunprotected takes care of 80% of instancesecurity needs tynamo.org - Apache Tapestry - Apache Shiro 13. What next? same model would work forHibernate, JDO.. push to Shiro? at least annotations... anything more is difficult becauseShiro is persistence agnostictynamo.org - Apache Tapestry - Apache Shiro 14. Thank you!For more information, visit :http://tynamo.org/tapestry-security-jpa+guideWhat do You think?tynamo.org - Apache Tapestry - Apache Shiro