Revision: 700
http://openutils.svn.sourceforge.net/openutils/?rev=700&view=rev
Author: fcarone
Date: 2008-02-25 09:38:38 -0800 (Mon, 25 Feb 2008)
Log Message:
-----------
More documentation added
Modified Paths:
--------------
trunk/openutils-hibernate-security/src/site/apt/index.apt
Added Paths:
-----------
trunk/openutils-hibernate-security/src/site/apt/rbac-acegi.apt
Modified: trunk/openutils-hibernate-security/src/site/apt/index.apt
===================================================================
--- trunk/openutils-hibernate-security/src/site/apt/index.apt 2008-02-25 14:08:41 UTC (rev 699)
+++ trunk/openutils-hibernate-security/src/site/apt/index.apt 2008-02-25 17:38:38 UTC (rev 700)
@@ -12,7 +12,9 @@
See the test classes for how to setup security and look at {{{apidocs/index.html}javadocs}} for more details.
+ If need more detail but you don't want to dig into the sources, then you can read this {{{rbac-acegi.html}document}}.
+
Released versions
Check it at {{{http://www.mvnrepository.com/artifact/net.sourceforge.openutils/openutils-hibernate-security}http://www.mvnrepository.com/artifact/net.sourceforge.openutils/openutils-hibernate-security}}
Added: trunk/openutils-hibernate-security/src/site/apt/rbac-acegi.apt
===================================================================
--- trunk/openutils-hibernate-security/src/site/apt/rbac-acegi.apt (rev 0)
+++ trunk/openutils-hibernate-security/src/site/apt/rbac-acegi.apt 2008-02-25 17:38:38 UTC (rev 700)
@@ -0,0 +1,40 @@
+ --------------------------
+ O p e n u t i l s
+ --------------------------
+ Filippo Carone
+ --------------------------
+
+openutils-hibernate-security - A Role Based Access Control library
+
+ This project proposes a Role Based approach to security, trying to be as hidden as possible to application developers.
+
+ A common test case is when you have different users who can access the same group of domain business objects and a
+policy to enforce access security is needed. For exaple, given a DummyDataObject with two properties, intValue and
+stringValue, you want UserA to access the DummyDataObject when intValue is 1 and UserB when intValue is 2.
+
+ In a typical RBAC environment, the user (or entity who does something) is called subject and a subject is tied to
+many roles. Within openutils, 1 user is contained in N groups and a group can have M roles, so you relate users
+to roles through groups. For our example let's map UserA to Role1 and UserB to Role2 (through 2 different groups,
+GroupA and GroupB, but groups are not important now).
+
+ The core of the openutils-hibernate-security is called SecurityRule. A SecurityRule defines which role can
+access/modify/create/delete which object (so who can do what on something). To enforce our example policy we add
+2 SecurityRules, using the following notation:
+
+ RoleN - Bean - property - value - Modifier (EQUALS, NOT) - Permission (LOAD, CREATE, DELETE, MODIFY)
+
+ So:
+
+ SecurityRule 1:
+ Role1 - DummyDataObject - intValue - 1 - EQUALS - LOAD
+
+ SecurityRule 2:
+ Role2 - DummyDataObject - intValue - 2 - EQUALS - LOAD
+
+ With the given scheme, users with roles Role1 and Role2 can access in readonly mode the DummyDataObject instances with
+respectively intValue equals to 1 and 2. If you want to make Role2 access the DummyDataObjects in read-write mode, the
+SecurityRule 2 becomes:
+
+ Role2 - DummyDataObject - intValue - 2 - EQUALS - LOAD, MODIFY
+
+ In this case, users with Role2 won't be able to either create or delete DummyDataObjects when intValue is 2.
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
