taylor 2004/01/09 15:48:23
Added: docs SecurityDesignNotes.txt securitySchema_v1.1.pdf
Log:
Le Strat Security Proposal
Revision Changes Path
1.1 jakarta-jetspeed-2/docs/SecurityDesignNotes.txt
Index: SecurityDesignNotes.txt
===================================================================
* Design Goals:
1. Implement Jetspeed security using JAAS.
2. Use AOP/interception when appropriate for authorization.
Approach:
A user is represented by a combination of Subject (java.security.auth.Subject) and
Preferences (java.util.prefs.Preferences).
The UserPrincipal provide the link between Subject and Preferences as user
preferences are stored under:
/user/${UserPrincipal}
-----------------------------------
Authentication
-----------------------------------
Authentication leverage JAAS.
Jetspeed default implementation provide an RdbmsLoginModule that allows
user authentication against user credentials stored in a database.
Upon authentication a Subject is created with the following principals:
- UserPrincipal (e.g. /user/theUsername)
- RolePrincipal
- GroupPrincipal
-----------------------------------
Authorization
-----------------------------------
* What are we securing:
Many portal resources are being secured: pages, portlets, tabs, etc.
Portal resources have various security policy associated to them for the following
type of Principals:
- UserPrincipal
- RolePrincipal
- GroupPrincipal
* How are we securing it:
Securing resources will leverage a custom policy implementation and permissions.
The custom policy implementation
(o.a.j.security.auth.RdbmsPolicy) will allow to apply policies as follow:
grant principal o.a.j.security.UserPrincipal "theUserPrincipal" {
permission o.a.j.security.PagePermission "mypage", "view";
permission o.a.j.security.PortletPermission "myportlet",
"view,edit,minimize,maximize";
permission o.a.j.security.TabPermission "mytab", "view";
};
grant principal o.a.j.security.RolePrincipal "theRolePrincipal" {
permission o.a.j.security.PagePermission "mypage", "view";
permission o.a.j.security.PortletPermission "myportlet",
"view,edit,minimize,maximize";
permission o.a.j.security.TabPermission "mytab", "view";
};
grant principal o.a.j.security.GroupPrincipal "theGroupPrincipal" {
permission o.a.j.security.PagePermission "mypage", "view";
permission o.a.j.security.PortletPermission "myportlet",
"view,edit,minimize,maximize";
permission o.a.j.security.TabPermission "mytab", "view";
};
* The following permission are anticipated:
TODO
* How do we access it:
Given that a user is authenticated that the current subject is the one of that user,
we would check for permission
doing:
Subject.doAs(loginContext.getSubject(), new PrivilegedAction()
{
public Object run()
{
PortletPermission perm1 = new PortletPermission("myportlet", "view");
System.out.println("\t\t[TestRdbmsPolicy] Check perm1.");
AccessController.checkPermission(perm1);
return null;
}
});
* Configuring the new policy
The java security provider is set at runtime through the Policy.setPolicy()
static access.
Check the TestRdbmsPolicy and javadoc for more info.
* The RDBMS policy implementation:
The assumption is made that policies will always look like:
grant principal ...
Therefore the RDBMS policy implementation will grant access for all classes.
Codebase support and CodeSource support is NOT implemented.
* Link between the Security and Preferences services:
The link between the Security service and the Preferences services is performed
using
security_principal.name and pref_node.full_path
The name of a user principal in the security layer should match the full path of
that user
preferences root in the prefs layer:
e.g: /user/theUserPrincipal
* Managing groups and roles:
Use java.util.prefs.Preferences to store roles and groups as user preferences.
<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>
This defines the following group and role hierarchy:
/group1/groupid1.1/groupid1.1.1
and
/role1/roleid1.1/roleid1.1.1
Where map can define group or role custom properties
E.g: For roles, we 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 group, a portal could use group to describe organization and have custom
property such as address, city, etc associated with the organization/group.
Readings:
http://java.sun.com/j2se/1.4.2/docs/api/index.html
http://www.ufr-info-p7.jussieu.fr/hf/jdk1.3/docs/guide/security/Acl.html
http://www.theserverside.com/resources/AspectJreview.jsp
http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc2.html
http://www-106.ibm.com/developerworks/library/j-jaas/?n-j-442
1.1 jakarta-jetspeed-2/docs/securitySchema_v1.1.pdf
<<Binary file>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
