You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by ep...@apache.org on 2003/12/06 00:35:14 UTC
cvs commit: jakarta-turbine-fulcrum/security/xdocs changes.xml tasks.xml index.xml
epugh 2003/12/05 15:35:14
Modified: security/xdocs changes.xml tasks.xml index.xml
Log:
Updated docs for breakup of projects
Revision Changes Path
1.11 +47 -30 jakarta-turbine-fulcrum/security/xdocs/changes.xml
Index: changes.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-fulcrum/security/xdocs/changes.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- changes.xml 6 Nov 2003 16:55:21 -0000 1.10
+++ changes.xml 5 Dec 2003 23:35:14 -0000 1.11
@@ -6,49 +6,66 @@
</properties>
<body>
- <release version="1.0-alpha-3" date="in cvs">
- <action dev="epugh" type="add">
- Realized the one size fits all ACL doesn't work.. ACL's are tied to models. Now, there is
- an AccessControlList interface, but it is just a marker. Each model implements the ACL.
- Added a Memory implementaiton of the Turbine model.
- </action>
- <action dev="epugh" type="fix">
- All the various SecuritySet implementations base their logic off their Name, not the ID, or
- Object type. Fixes problems with comparisons when you have various subclasses.
- </action>
- <action dev="epugh" type="fix">
- For a SecurityEntityImpl, if the name is null then throw an InvalidParameterException.
- </action>
- <action dev="epugh" type="add">
- Add ModelManager interface and SimpleModelManager and TurbineModelManager
- component that explicitly contains the relationship between the various
- entities.
+ <release version="1.0-alpha-4" date="in cvs">
+ <action dev="epugh" type="add">
+ Added the "Basic" model and supplied implementations for memory, NT, and Hibernate.
+ </action>
+ <action dev="epugh" type="add">
+ AccessControlLists are now pluggable via the ACLFactory implementation you supply.
+ </action>
+ <action dev="epugh" type="update">
+ Vastly refactored the builds into multiple projects. The api related onces are <code>/api</code> and <code>/spi</code>.
+ The implementation details are in <code>/memory</code>,<code>/hibernate</code>, and<code>/nt</code>. And lastly, there
+ are two adapters: <code>/adapters/turbine</code> and <code>/adapters/opensymphony</code>.
+ </action>
+ <action dev="epugh" type="remove">
+ Tossed the various Torque code. It isn't unit tested, and was causing lots of work that couldn't be tested.. At some
+ point, if there is demand, we can put it back.
+ </action>
+ </release>
+ <release version="1.0-alpha-3" date="n/a">
+ <action dev="epugh" type="add">
+ Realized the one size fits all ACL doesn't work.. ACL's are tied to models. Now, there is
+ an AccessControlList interface, but it is just a marker. Each model implements the ACL.
+ Added a Memory implementaiton of the Turbine model.
+ </action>
+ <action dev="epugh" type="fix">
+ All the various SecuritySet implementations base their logic off their Name, not the ID, or
+ Object type. Fixes problems with comparisons when you have various subclasses.
+ </action>
+ <action dev="epugh" type="fix">
+ For a SecurityEntityImpl, if the name is null then throw an InvalidParameterException.
+ </action>
+ <action dev="epugh" type="add">
+ Add ModelManager interface and SimpleModelManager and TurbineModelManager
+ component that explicitly contains the relationship between the various
+ entities.
</action>
</release>
- <release version="1.0-alpha-2" date="10-29-2003">
- <action dev="epugh" type="update">
- Change all get(Role/Group/User/Permssion)Instance from throwing an UnknownEntityException to
- throwing a DataBackendException. There is no entity id when creating a new one yet!
- </action>
+ <release version="1.0-alpha-2" date="10-29-2003">
+ <action dev="epugh" type="update">
+ Change all get(Role/Group/User/Permssion)Instance from throwing an UnknownEntityException to
+ throwing a DataBackendException. There is no entity id when creating a new one yet!
+ </action>
<action dev="epugh" type="add">
- Added an adapter to OSUser. This allows OSUser to query Fulcrum Security
- for users and to authenticate them via Fulcrum Security authenticators.
+ Added an adapter to OSUser. This allows OSUser to query Fulcrum Security
+ for users and to authenticate them via Fulcrum Security authenticators.
</action>
</release>
<release version="1.0-alpha-1" date="2003-10-21">
<action dev="epugh" type="add">
- Added an IntegerConverter so the adapter can be used with fulcrum SPI's
- that use Long/Integer/String (as a number) as the ID.
+ Added an IntegerConverter so the adapter can be used with fulcrum SPI's
+ that use Long/Integer/String (as a number) as the ID.
</action>
<action dev="epugh" type="add">
- Converted id to Object. Now the various SPI's cast the Object type
- to whatever they want to use.
+ Converted id to Object. Now the various SPI's cast the Object type
+ to whatever they want to use.
</action>
<action dev="epugh" type="add">
- Pluggable Authenticators done. Added NT, crypto, and plain text.
+ Pluggable Authenticators done. Added NT, crypto, and plain text.
</action>
<action dev="epugh" type="add">
- Hibernate based Simple model done.
+ Hibernate based Simple model done.
</action>
<action dev="epugh" type="update">
Converted all id's for security objects to "long" values to prevent running out of numbers.
1.4 +10 -102 jakarta-turbine-fulcrum/security/xdocs/tasks.xml
Index: tasks.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-fulcrum/security/xdocs/tasks.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- tasks.xml 25 Aug 2003 01:07:11 -0000 1.3
+++ tasks.xml 5 Dec 2003 23:35:14 -0000 1.4
@@ -9,18 +9,11 @@
<body>
<section name="Tasks">
<p>
- Lists of todos and ideas for future versions.
+ Lists of todos and ideas for future versions.
</p>
<p>
-
- <ul>
- <li>
- The Turbine model was taken from the Turbine security. However, I really don't quite grok it yet. Therefore all the
- unit tests have been written agains the Simple model, which is what I want to implement.
- </li>
- <li>
- Need to provide an Memory implementation of the Turbine model for unit testing.
- </li>
+
+ <ul>
<li>
Need to use the encryption component!
</li>
@@ -31,106 +24,21 @@
grunt work.
</li>
<li>
- Convert all avalon components to use Servicable. Per this email:
-<pre>
-Eric Pugh wrote:
-> So, if I am stuck currently using ECM, then I need to keep it. Or, I guess
-> if I think users of my wrapper are running it in ECM as well..
-
-yes.
-
-> Any suggestions on what the best way to move forward? Deprecate the
-> interface or something? Release two versions of the wrapper, one with and
-> one without?
-
-simply keep implementing Component in all your wrappers, but do move to
-use Servicable/ServiceManager. So:
-
-class MyImpl implements My, Servicable, Component
-{
- service( ServiceManager sm )
- {
- MyOtherComp o = (MyOtherComp)sm.lookup( "blah" );
- }
-}
-
-that way, MyImpl won't suffer if the implementation for MyOtherComp has
-its 'Component' marker removed. And yes, this works in the latest
-release of ECM, too.
-
-> I guess, now that I grok the docs a bit better, that I am now supposed to
-> use Serviceable and the ServiceManager in all the places I had Composable
-> and ComponentManager? I guess my other question is whether to use upgrade
-> Turbine's AvalonComponentService to use Fortress or Merlin. The overview
-> doc (http://avalon.apache.org/containers/index.html) seems to suggest
-> Fortress, however Merlin has a release out.
-
-Fortress has a final release, merlin does not. The releases Steve is
-making available atm are snapshots of the Merlin3 tree, not final releases.
-
-Based on my knowledge of the needs in turbine, I would suggest going
-with fortress if you decide to upgrade. Merlin atm offers a kitchen sink
-or two you guys don't need :D
-
-cheers,
-
-- LSD
-
-</pre>
+ Try and figure out how to get both NTLM authentication, as well as retrieving the password, or the groups
+ directly to use with "Basic" security model.
</li>
+ <li>
+ Upgrade to using Merlin for unit tests instead of ECM.. Also have demos showing using the security module
+ in Merlin.
+ </li>
</ul>
</p>
</section>
<section name="Things to Resolve">
- <subsection name="Naming">
- <p>
- <ul>
- <li>
- Right now I don't like the names of the types of Model's.. I think "Simple" and "Turbine" are
- terribly non descriptive names.
- </li>
- <li>
- Should SPI implementations have the same name? Right now the name of the model is in the name of the SPI implementator like
- <code>org.apache.fulcrum.security.spi.memory.simple.SimpleGroupManagerImpl</code>. Should it be called
- <code>o.a.f.s.spi.memory.simple.GroupManger</code>? Is that confusing if there is also <code>o.a.f.s.spi.memory.turbine.GroupManager</code>.
- <br/>
- Although, I guess you would only have a single GroupManager per app? I could see have <code>o.a.f.s.spi.memory.simple.UserManager</code>
- as well as <code>o.a.f.s.spi.nt.simple.GroupManager</code>. But not two GroupManagers.
- </li>
- <li>
- Lastly, should it be o.a.f.s.spi.hibernate.simple and o.a.f.s.spi.memory.simple or should it be o.a.f.s.spi.simple.hibernate and o.a.f.s.spi.simple.memory?
- With all the spi types together, like hibernate or memory, it might be cleaner sharing code between the packags.
- </li>
-
- <li>
- Related, should the interfaces like <code>SimpleGroupManager</code> extends <code>GroupManager</code>? Or should they instead
- be called something like <code>GroupModel</code> or <code>SimpleGroupModel</code> because they specify the model of how the
- bits and pieces fit togther? However, when you are doing a grant/revoke type action you would cast to <code>((GroupModel)groupManager).revokeAll()</code>
- versus casting to <code>((SimpleGroupManager)groupManager).revokeAll()</code>. So you cast to GroupModel for model changes, and to SimpleGroupManager for
- entity changes.. Not sure.. smells maybe of needless complexity...
-
- </li>
- </ul>
- </p>
- </subsection>
+
- <subsection name="Access Control Lists">
- <p>
- A couple of the objects are hardcoded when being created.
- <ul>
- <li>
- the DefaultAccessControlList is the only option in the SimpleUserManager. It is hardcoded, versus
- using a factory service. Should a factory be used? If so, is it the fulcrum factory service, or
- does it look up the Factory as an Avalon component?
- </li>
- <li>
- Is there a performance gain from pooling ACL's? They are very specific to the user however.
- </li>
- </ul>
- </p>
- </subsection>
1.8 +45 -48 jakarta-turbine-fulcrum/security/xdocs/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-fulcrum/security/xdocs/index.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- index.xml 6 Nov 2003 16:55:21 -0000 1.7
+++ index.xml 5 Dec 2003 23:35:14 -0000 1.8
@@ -11,12 +11,12 @@
<section name="Overview">
<p>
- This component attempts to provide a security framework It is written
- for use in Turbine but it has been expanded and can be used in any container compatible
- with Avalon's ECM container.
+ This component provides a highly flexible security framework It is based on code from the
+ Turbine framework, but has been expanded and can be used in any container compatible
+ with the Avalon framework.
<ul>
<li>Allow pluggability via Avalon components of various entities.</li>
- <li>Explicit Model interface allows entities to be glued together.</li>
+ <li>Explicit Model interface allows generic entities to be glued together in a custom model very quickly.</li>
<li>Provide adapters to various other security systems</li>
<li>Solve most common problems in dealing with security</li>
<li>Not enforce assumptions about how a security framework should be setup.</li>
@@ -25,73 +25,62 @@
<subsection name="Matrix">
<table>
<tr>
- <th/><th colspan="4">Simple Model</th><th colspan="4">Turbine Model</th>
+ <th/><th colspan="2">Basic Model</th><th colspan="4">Dynamic Model</th><th colspan="4">Turbine Model</th>
</tr>
<tr>
- <th/><th>User</th><th>Group</th><th>Role</th><th>Permission</th><th>User</th><th>Group</th><th>Role</th><th>Permission</th>
+ <th/><th>User</th><th>Group</th><th>User</th><th>Group</th><th>Role</th><th>Permission</th><th>User</th><th>Group</th><th>Role</th><th>Permission</th>
</tr>
- <tr><th>Memory</th><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td></tr>
- <tr><th>Hibernate</th><td>X</td><td>X</td><td>X</td><td>X</td><td></td><td></td><td></td><td></td></tr>
- <tr><th>Torque</th><td></td><td></td><td></td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr>
- <tr><th>Passive</th><td></td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td></tr>
- <tr><th>NT</th><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
+ <tr><th>Memory</th><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td></tr>
+ <tr><th>Hibernate</th><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td></td><td></td><td></td><td></td></tr>
+ <tr><th>NT</th><td>X</td><td>X</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
</table>
</subsection>
</section>
<section name="Common Security Implementations">
<p>
- There are a couple common approaches to security. Currently this component tries to solve
- two common setups for security.
+ The two most common models for security are embodied in the "Basic" and "Dynamic" models. A third model, "Turbine",
+ demonstrates customizing the "Dynamic" model by adding a concept of a global group.
</p>
- <subsection name="Simple">
+ <subsection name="Dynamic">
<p>
- For lack of a better name, this one is called Simple. In it, you have a set of permissions
- that are related in a many to many relation ship with a set or roles. Those roles are related
+ For lack of a better name, this one is called Dynamic because you can configure all the relationships.
+ In it, you have a set of permissions that are related in a many to many relation ship with a set or roles.
+ Those roles are related
in a many to many relationship with a set of groups. A user is in a many to many relationship
- with a set of groups. <i>note: I will try and get a diagram. any suggestions on diagram tools?</i>
- Also, after seeing some other schemes, maybe a better name would be <i>Complex</i> or <i>Very Flexible</i>
- as it is a much more complex approach.
+ with a set of groups. <i>note: I will try and get a diagram. any suggestions on diagram tools?</i>
</p>
<p>
- The <code>memory</code> package currently implements this security model. However, if you
- change the SimpleModel objects, you could implement the second one, "Turbine".
+ The <code>memory</code> and <code>hibernate</code> packages currently implements this security model.
</p>
</subsection>
<subsection name="Turbine">
<p>
- This model is based on what the Turbine application server uses. In it, permissions are in a
- many to many relationship with Roles. However, what makes this different is that instead of roles
+ This model is based on what the Turbine application server uses, and leverages the Dynamic model. It merely adds
+ the concept of a "global group" which is a toplevel group to the Dynamic model.
+ However, what makes this different is that instead of roles
being related just to groups, there instead is a many to many relationship between users and
groups and roles. So you pick a user, pick their role, and their group, and that is their permissions.
- This strikes me as a maintence nightmare, why actually have a group entity?
- <i>note: I will try and get a diagram. any suggestions on diagram tools?</i>
- </p>
- <p>
- The <code>torque</code> package currently implements this security model. <strong>WARNING:
- this code hasn't been tested at all. It only compiles.</strong>
- </p>
+ </p>
</subsection>
- <subsection name="UsersAndGroup (OSUser Model)">
+ <subsection name="Basic">
<p>
- This model is based on what OSUser implements. In it, you have users, and groups, and security
+ This model is very simple and was originally inspired by OSUser's security model. In it, you have users, and groups, and security
is based on a user belonging to a group. Users can belong to multiple groups. So groups become
- the equivalent of roles/permissions. So, when an ACL class asks: <code>acl.hasRole("someRole")</code>
- what it is really asking is whether the user is part of a group or not.
+ the equivalent of roles/permissions.
</p>
<p>
- <strong>This model has NOT yet been implemented. If there is interest, it should be very easy to
- do.</strong>
+ The <code>memory</code>, <code>nt</code>, and <code>hibernate</code> packages currently implements this security model.
</p>
</subsection>
</section>
<section name="Simple">
- <subsection name="Usage of Simple InMemory component">
+ <subsection name="Usage of InMemory components">
<p>
- The InMemory components implement the Simple model. All data is strictly in memory, and is
+ The InMemory components implement the Basic model. All data is strictly in memory, and is
not persisted. Therefore when your application stops, all values are lost. However, this is
very useful in unit testing and prototyping using the Security component. Notice how role,
user, group, and permission managers are all Avalon components as well? This allows you to swap one
@@ -102,7 +91,8 @@
</subsection>
<subsection name="Configuration">
<p>
- This uses the integrated role and component config XML.
+ This uses the integrated role and component config XML. Check the /src/test directory for the most uptodate
+ examples of the configuration files used in unit testing!
</p>
<p>
<source>
@@ -115,26 +105,26 @@
<component
role="org.apache.fulcrum.security.UserManager"
- class="org.apache.fulcrum.security.spi.memory.simple.MemoryUserManagerImpl">
+ class="org.apache.fulcrum.security.memory.MemoryUserManagerImpl">
</component>
<component
role="org.apache.fulcrum.security.GroupManager"
- class="org.apache.fulcrum.security.spi.memory.simple.MemoryGroupManagerImpl">
+ class="org.apache.fulcrum.security.memory.MemoryGroupManagerImpl">
</component>
<component
role="org.apache.fulcrum.security.RoleManager"
- class="org.apache.fulcrum.security.spi.memory.simple.MemoryRoleManagerImpl">
+ class="org.apache.fulcrum.security.memory.MemoryRoleManagerImpl">
</component>
<component
role="org.apache.fulcrum.security.PermissionManager"
- class="org.apache.fulcrum.security.spi.memory.simple.MemoryPermissionManagerImpl">
+ class="org.apache.fulcrum.security.memory.MemoryPermissionManagerImpl">
</component>
<component
role="org.apache.fulcrum.security.ModelManager"
- class="org.apache.fulcrum.security.spi.memory.simple.MemoryModelManagerImpl">
+ class="org.apache.fulcrum.security.memory.basic.MemoryModelManagerImpl">
</component>
</my-system>
]]>
@@ -179,13 +169,20 @@
</subsection>
</section>
-<section name="SPI Details">
+<section name="Implementation Details">
<subsection name="Hibernate">
<p>
- With the Hibernate SPI, you can just subclass the HibernateSimpleUser object, provide your own mapping .hbm file
- and then any additional user properties will be persisted! Very very easy customization to your environment!
+ With the Hibernate SPI, you can just subclass the BasicUser/DynamicUser class, or implement the User interface, provide your own mapping .hbm file
+ and then any additional user properties will be persisted! Very easy customization for your environment!
</p>
- </subsection>
+ </subsection>
+ <subsection name="NT">
+ <p>
+ If you use the BasicModel with the NT implementation, you have a wholly NT based authentication scheme! The groups map onto NT groups, while the
+ users are authenticated against NT as well. This does require you to ask your users for their NT username and password however, we
+ don't have NTLM working as yet.
+ </p>
+ </subsection>
</section>
</body>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org