You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by dl...@apache.org on 2005/07/31 18:47:22 UTC
svn commit: r226661 - in
/portals/jetspeed-2/trunk/components/security/xdocs: hierarchy.xml index.xml
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