portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tay...@apache.org
Subject cvs commit: jakarta-jetspeed-2/docs SecurityDesignNotes.txt securitySchema_v1.1.pdf
Date Fri, 09 Jan 2004 23:48:23 GMT
taylor      2004/01/09 15:48:23

  Added:       docs     SecurityDesignNotes.txt securitySchema_v1.1.pdf
  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.
  A user is represented by a combination of Subject (java.security.auth.Subject) and Preferences
  The UserPrincipal provide the link between Subject and Preferences as user preferences are
stored under:
  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
  * 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:
  * 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
  Subject.doAs(loginContext.getSubject(), new PrivilegedAction()
     public Object run()
        PortletPermission perm1 = new PortletPermission("myportlet", "view");
        System.out.println("\t\t[TestRdbmsPolicy] Check 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 name="role1">
      <map />
          <node name="roleid1.1">
          <map />
  	    <node name="roleid1.1.1">
              <map />
  This defines the following group and role hierarchy:
  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.
  1.1                  jakarta-jetspeed-2/docs/securitySchema_v1.1.pdf
  	<<Binary file>>

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

View raw message