<?xml version="1.0"?>
<!--
Copyright 2004 The Apache Software Foundation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<document>
<properties>
	<title>Jetspeed 2 Security Architecture</title>
    <authors>
      <person name="David Le Strat" email="dlestrat@apache.org"/>
    </authors>
</properties>
<body>
<section name="Overview">
<p>
Jetspeed 2 security architecture provides a comprehensive suite of security services
that can be used to protect a wide ranging type of portal resources.  At its core, Jetspeed 2
security services rely entirely on JAAS to provide authentication and authorization services to
the portal:
</p>
<ul>
<li>
Authentication services are implemented through the use of JAAS login modules.
</li>
<li>
Authorization services are implemented through the use of custom JAAS policies.
</li>
</ul>
<p>
Both authentication and authorization services have been implemented with the goal of providing a direct
plugin to the underlying application server security framework.  Jetspeed 2 can leverage the underlying
application server login module as well as through the use of JACC, the application server policy management
capabilities available in J2EE 1.4 (see <a href="http://java.sun.com/j2ee/javaacc/">API Specifications</a>).
</p>
</section>
<section name="Jetspeed 2 Security Service">
<p>
JAAS defines the contract for authentication and authorization but does not specify any guidelines for the management
of the security resources.  Jetspeed 2 provide a modular set of components aims at providing management functionality
for the portal security components.
</p>
<p>
Leveraging Jetspeed 2 component, architecture, the security services provide a set of loosing coupled components providing
specilized services:
</p>
<ul>
<li>
UserManager: Service providing user management capabilities.
</li>
<li>
GroupManager: Service providing group management capabilities.
</li>
<li>
RoleManager: Service providing role management capabilities.
</li>
<li>
PermissionManager: Service providing permission management capabilities.
</li>
</ul>
</section>
<section name="A Modular and Pluggable Architecture">
<p><img src="images/components.jpg" align="right" border="0" hspace="1" vspace="2"/>
Jetspeed 2 security services are founded on a set of modular and extensible security modules exposed through an SPI model.
The SPI model provides the ability to modify the behavior of the security services through the modification and configuration
of specialized handlers.  For instance, Jetspeed security services can be configured to retrieve user security principals through
the default Jetspeed store or through an LDAP store or both.<br/>
A <code>SecurityProvider</code> exposes the configured SPI handlers to the security services.  Jetspeed component assembly 
(based on Spring) architecture provides an easy way to reconfigure the security services to satisfy the needs of a 
specific implementation.
</p>
</section>
<section name="Role Based Access Control">
<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:
</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>