portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlest...@apache.org
Subject svn commit: r226661 - in /portals/jetspeed-2/trunk/components/security/xdocs: hierarchy.xml index.xml
Date Sun, 31 Jul 2005 16:47:22 GMT
Author: dlestrat
Date: Sun Jul 31 09:47:20 2005
New Revision: 226661

URL: http://svn.apache.org/viewcvs?rev=226661&view=rev
Log:
More security documentation.

Modified:
    portals/jetspeed-2/trunk/components/security/xdocs/hierarchy.xml
    portals/jetspeed-2/trunk/components/security/xdocs/index.xml

Modified: portals/jetspeed-2/trunk/components/security/xdocs/hierarchy.xml
URL: http://svn.apache.org/viewcvs/portals/jetspeed-2/trunk/components/security/xdocs/hierarchy.xml?rev=226661&r1=226660&r2=226661&view=diff
==============================================================================
--- portals/jetspeed-2/trunk/components/security/xdocs/hierarchy.xml (original)
+++ portals/jetspeed-2/trunk/components/security/xdocs/hierarchy.xml Sun Jul 31 09:47:20 2005
@@ -24,11 +24,148 @@
     <body>
         <section name="Hierarchy Management Overview">
             <p>
+                Two hierarchy resolution strategies are supported for authorization decisions:
+                <ul>
+                    <li>
+                        Hierarchy resolution by Generalization: This is the default hierarchy
resolution in Jetspeed. If a hierarchy uses a generalization
+                        strategy, each role is more general than the previous one. For instance,
if a user has the role [roleA.roleB.roleC] then
+                        <code>user.getSubject().getPrincipals()</code>
+                        returns:
+                        <ul>
+                            <li>/role/roleA</li>
+                            <li>/role/roleA/roleB</li>
+                            <li>/role/roleA/roleB/roleC</li>
+                        </ul>
+                    </li>
+                    <li>
+                        Hierarchy resolution by Aggregation: If a hierarchy uses a aggregation
strategy, the higher role is responsible for a superset of the
+                        activities of the lower role. For instance, if the following roles
are available:
+                        <ul>
+                            <li>roleA</li>
+                            <li>roleA.roleB</li>
+                            <li>roleA.roleB.roleC</li>
+                        </ul>
+                        If a user has the role [roleA] then,
+                        <code>user.getSubject().getPrincipals()</code>
+                        returns:
+                        <ul>
+                            <li>/role/roleA</li>
+                            <li>/role/roleA/roleB</li>
+                            <li>/role/roleA/roleB/roleC</li>
+                        </ul>
+                    </li>
+                </ul>
+            </p>
+            <p>
+                As described in the
+                <a href="atz-spi.html">authorization SPI section</a>
+                , the
+                <code>SecurityMappingHandler</code>
+                is configured with a specific hierarchy strategy for group and role hierarchy
management. See the
+                <a href="config.html#security-spi-atz_xml">authorization SPI configuration</a>
+                for a configuration example.
             </p>
         </section>
         <section name="Leveraging Preferences to Manage Hierarchies">
             <p>
+                The default hierarchy management implementation resolves the hierarchy strategy
by leveraging Jetspeed 2's
+                <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/Preferences.html">java.util.prefs.Preferences</a>
+                implementation. The
+                <code>Preferences</code>
+                implementation provides the underlying structure in Jetspeed to store user
attributes, and roles and groups definitions. The
+                <code>Preferences</code>
+                model provides a hierarchy model that is leveraged to store the base roles
and groups hierarchy upon which various resolving strategies can be
+                applied (resolution by generalization or aggregation).
+            </p>
+            <p>
+                See Jetspeed 2
+                <a href="/multiproject/jetspeed-prefs/index.html">Preferences implementation
section</a>
+                for more information.
             </p>
+            <subsection name="How does this work?">
+                <p>
+                    The
+                    <code>SecurityMappingHandler</code>
+                    implementation resolves the mappings between roles and groups. Let's
say that we want to find out the roles mapping to a specific group
+                    name. To do so, the
+                    <code>SecurityMappingHandler</code>
+                    implements a
+                    <code>getRolePrincipalsInGroup(String groupFullPathName)</code>
+                    method. In this method, the group name is mapped to a specific
+                    <code>Preferences</code>
+                    node. According to a given hierarchy resolution strategy (see
+                    <a href="#Hierarchy_Management_Overview">overview section</a>
+                    ), being in [group A] may mean belonging to a set of groups; the HierarchyResolver
is used to do so as illustrated below:
+                    <source>
+                        <![CDATA[
+public Set getRolePrincipalsInGroup(String groupFullPathName)
+{
+   ...
+   Preferences preferences = Preferences.userRoot().node(
+       GroupPrincipalImpl.getFullPathFromPrincipalName(groupFullPathName));
+   String[] fullPaths = groupHierarchyResolver.resolve(preferences);
+   ...
+}]]>
+                    </source>
+                    The resulting groups are then used to find all associated roles.
+                </p>
+                <p>
+                    As a result of this implementation, the name of a role principal (<code>Principal</code>

+                    <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/security/Principal.html#getName()">getName()</a>)

+                    in the security layer should match the full path of that user preferences
+                    root in the preferences layer (<code>Preference</code> 
+                    <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/Preferences.html#absolutePath()">absolutePath()</a>;
e.g:
+                    <code>/role/theRolePrincipal</code>
+                    ).
+                </p>
+                <p>
+                    Group and roles hierarchy are stored in the
+                    <code>Preferences</code>
+                    layer as follow (the output of <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/Preferences.html#exportNode(java.io.OutputStream)">
+                    exportNode()</a> for Jetspeed's RBMS <code>Preferences</code>
implementation):
+                    <source>
+                        <![CDATA[
+<preferences EXTERNAL_XML_VERSION="1.0">
+<root type="user">
+<map />
+    <node name="group1">
+    <map />
+        <node name="groupid1.1">
+        <map />
+	    <node name="groupid1.1.1">
+            <map />
+            </node>
+        </node>
+    </node>
+
+    <node name="role1">
+    <map />
+        <node name="roleid1.1">
+        <map />
+	    <node name="roleid1.1.1">
+            <map />
+            </node>
+        </node>
+    </node>
+</root>]]>
+                    </source>
+                    This structure would define the following group and role hierarchy:
+                    <ul>
+                        <li>
+                            <code>/group1/groupid1.1/groupid1.1.1</code>
+                        </li>
+                        <li>
+                            <code>/role1/roleid1.1/roleid1.1.1</code>
+                        </li>
+                    </ul>
+                    Additionally, in this model, the
+                    <code>map</code>
+                    element can define groups or roles custom properties. For instance, a
role could have a rule custom property (or a pointer to a rule) that
+                    allow rule based role definition tied to some rule engine (Drools for
instance) and is validated when the isInRole method is invoked. For
+                    groups, a portal could use group to describe organization and have custom
property such as address, city, etc. associated with the
+                    organization/group.
+                </p>
+            </subsection>
         </section>
     </body>
 </document>

Modified: portals/jetspeed-2/trunk/components/security/xdocs/index.xml
URL: http://svn.apache.org/viewcvs/portals/jetspeed-2/trunk/components/security/xdocs/index.xml?rev=226661&r1=226660&r2=226661&view=diff
==============================================================================
--- portals/jetspeed-2/trunk/components/security/xdocs/index.xml (original)
+++ portals/jetspeed-2/trunk/components/security/xdocs/index.xml Sun Jul 31 09:47:20 2005
@@ -82,38 +82,8 @@
             <p>
                 Role based access control (RBAC) in Jetspeed 2 support multiple hierarchy
resolution strategies as defined in
                 <a href="http://www.doc.ic.ac.uk/~ecl1/papers/rbac99.pdf">The Uses
of Hierarchy in Access Control</a>
-                . Two hierarchy resolution strategies are supported for authorization decisions:
+                . See <a href="hierarchy.html">Hierarchy Management Overview</a>
for more information.
             </p>
-            <ul>
-                <li>
-                    Hierarchy resolution by Generalization: This is the default hierarchy
resolution in Jetspeed. If a hierarchy uses a generalization strategy,
-                    each role is more general than the previous one. For instance, if a user
has the role [roleA.roleB.roleC] then
-                    <code>user.getSubject().getPrincipals()</code>
-                    returns:
-                    <ul>
-                        <li>/role/roleA</li>
-                        <li>/role/roleA/roleB</li>
-                        <li>/role/roleA/roleB/roleC</li>
-                    </ul>
-                </li>
-                <li>
-                    Hierarchy resolution by Aggregation: If a hierarchy uses a aggregation
strategy, the higher role is responsible for a superset of the
-                    activities of the lower role. For instance, if the following roles are
available:
-                    <ul>
-                        <li>roleA</li>
-                        <li>roleA.roleB</li>
-                        <li>roleA.roleB.roleC</li>
-                    </ul>
-                    If a user has the role [roleA] then,
-                    <code>user.getSubject().getPrincipals()</code>
-                    returns:
-                    <ul>
-                        <li>/role/roleA</li>
-                        <li>/role/roleA/roleB</li>
-                        <li>/role/roleA/roleB/roleC</li>
-                    </ul>
-                </li>
-            </ul>
         </section>
     </body>
 </document>



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message