xdocs/proposals/security-service.xml - turbine-core - Git at Google

 <?xml version="1.0"?>
 <!--
 /*
  * Copyright 2001-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>Application Service Proposal</title>
   </properties>

 <body>

 <section name="Security Service">

 <ul>
   <li>
     UserManager should become a service in it's own right.
   </li>

   <li>
     ACL mechanism should become pluggable. A new interface ACLBuilder must
     be defined, the interface would have single method of 'Object
     buildACL(User)' signature. UserManagerService would have a property that
     would contain *service name* that implements ACLBuilder. buildACL will be an
     instance not class method, so a concrete instance of the service must be
     consulted.
   </li>

   <li>
     User object will have method of 'Object getACL()' signature that will
     delegate to UserManagerService, which in turn delegates to the
     configured ACLBuilder. It's OK to cache the returned object, since
     the ACLBuilder will keep references ACL objects internally, to reflect
     the changes of sercurity information at runtime. (rafal)
   </li>

   <li>
     TurbineSecurityService will be the default ACLBuilder shipped with the
     system.
   </li>

   <li>
     TurbineSecurityService should have it's OM/Peer classes Torque
     generated.
   </li>

   <li>
     Group should be could be renamed to 'Realm' or 'Domain'. This should
     decrease the confusion about it's meaning.
   </li>

   <li>
     Attributes of Roles/Groups/Permissions will be dropped. I don't think
     the idea catched on.
   </li>

   <li>
     User attributes should be moved into a separate table, or even two
     tables if we want to store meta information for user attributes.
     This will require a customized Peer class for User objects, but
     this will be easy with recent Torque's two-level class generation
   </li>

   <li>
     On session unbind event, only acces counters/timestamps should be
     updated not the whole data. This should fix the overriding of
     admin's changes by the unbound session problems. The information
     which attributes should be updated could be placed in user attribute
     meta-information table.
   </li>

   <li>
     All references to peers have to be removed from the interfaces.
     Anything peer specific must be pushed down into DBSecurityService.
   </li>

   <li>
     Allow multiple security service implementations to be run in
     tandem. This would allow a portion of a site to be controlled
     by an LDAP security service and another portion to be controlled
     by DB security services. More info about this is explained in
     the Policy Service proposal.
   </li>

   <li>
     All the security code has to be grouped together. Right now it's
     all over the place and rather confusing. The util code should be
     moved into the security services package, and the om/peer code
     for the DBSecurityService should be move into the package with
     the rest of the DBSecurityService code. Here's what I would
     propose for the new layout. This would require the deprecation
     of the location of a lot of the classes but I think it would
     help a lot with the ease of understanding.
   </li>
 </ul>

 <source test=""><![CDATA[
 .
 |-- BaseSecurityService.java
 |-- SecurityService.java
 |-- TurbineSecurity.java
 |-- UserManager.java
 |-- entity
 |   |-- Group.java
 |   |-- Permission.java
 |   |-- Role.java
 |   |-- SecurityEntity.java
 |   `-- User.java
 |-- impl
 |   |-- db
 |   |   |-- DBSecurityService.java
 |   |   |-- DBUserManager.java
 |   |   `-- entity
 |   |       |-- GroupPeer.java
 |   |       |-- PermissionPeer.java
 |   |       |-- RolePeer.java
 |   |       |-- RolePermissionPeer.java
 |   |       |-- SecurityObject.java
 |   |       |-- TurbineGroup.java
 |   |       |-- TurbinePermission.java
 |   |       |-- TurbineRole.java
 |   |       |-- TurbineUser.java
 |   |       |-- TurbineUserPeer.java
 |   |       |-- UserGroupRolePeer.java
 |   |       `-- UserPeer.java
 |   |-- ldap
 |   |   |-- LDAPSecurityConstants.java
 |   |   |-- LDAPSecurityService.java
 |   |   |-- LDAPUser.java
 |   |   |-- LDAPUserManager.java
 |   |   `-- util
 |   |       `-- ParseExceptionMessage.java
 |   `-- passive
 |       `-- PassiveUserManager.java
 `-- util
     |-- AccessControlException.java
     |-- AccessControlList.java
     |-- DataBackendException.java
     |-- EntityExistsException.java
     |-- GroupSet.java
     |-- PasswordMismatchException.java
     |-- PermissionSet.java
     |-- RoleSet.java
     |-- TurbineSecurityException.java
     `-- UnknownEntityException.java

 ]]></source>

 </section>

 </body>
 </document>
	<?xml version="1.0"?>
	<!--
	/*
	* Copyright 2001-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>Application Service Proposal</title>
	</properties>

	<body>

	<section name="Security Service">

	<ul>
	<li>
	UserManager should become a service in it's own right.
	</li>

	<li>
	ACL mechanism should become pluggable. A new interface ACLBuilder must
	be defined, the interface would have single method of 'Object
	buildACL(User)' signature. UserManagerService would have a property that
	would contain service name that implements ACLBuilder. buildACL will be an
	instance not class method, so a concrete instance of the service must be
	consulted.
	</li>

	<li>
	User object will have method of 'Object getACL()' signature that will
	delegate to UserManagerService, which in turn delegates to the
	configured ACLBuilder. It's OK to cache the returned object, since
	the ACLBuilder will keep references ACL objects internally, to reflect
	the changes of sercurity information at runtime. (rafal)
	</li>

	<li>
	TurbineSecurityService will be the default ACLBuilder shipped with the
	system.
	</li>

	<li>
	TurbineSecurityService should have it's OM/Peer classes Torque
	generated.
	</li>

	<li>
	Group should be could be renamed to 'Realm' or 'Domain'. This should
	decrease the confusion about it's meaning.
	</li>

	<li>
	Attributes of Roles/Groups/Permissions will be dropped. I don't think
	the idea catched on.
	</li>

	<li>
	User attributes should be moved into a separate table, or even two
	tables if we want to store meta information for user attributes.
	This will require a customized Peer class for User objects, but
	this will be easy with recent Torque's two-level class generation
	</li>

	<li>
	On session unbind event, only acces counters/timestamps should be
	updated not the whole data. This should fix the overriding of
	admin's changes by the unbound session problems. The information
	which attributes should be updated could be placed in user attribute
	meta-information table.
	</li>

	<li>
	All references to peers have to be removed from the interfaces.
	Anything peer specific must be pushed down into DBSecurityService.
	</li>

	<li>
	Allow multiple security service implementations to be run in
	tandem. This would allow a portion of a site to be controlled
	by an LDAP security service and another portion to be controlled
	by DB security services. More info about this is explained in
	the Policy Service proposal.
	</li>

	<li>
	All the security code has to be grouped together. Right now it's
	all over the place and rather confusing. The util code should be
	moved into the security services package, and the om/peer code
	for the DBSecurityService should be move into the package with
	the rest of the DBSecurityService code. Here's what I would
	propose for the new layout. This would require the deprecation
	of the location of a lot of the classes but I think it would
	help a lot with the ease of understanding.
	</li>
	</ul>

	<source test=""><![CDATA[
	.
	\|-- BaseSecurityService.java
	\|-- SecurityService.java
	\|-- TurbineSecurity.java
	\|-- UserManager.java
	\|-- entity
	\| \|-- Group.java
	\| \|-- Permission.java
	\| \|-- Role.java
	\| \|-- SecurityEntity.java
	\| `-- User.java
	\|-- impl
	\| \|-- db
	\| \| \|-- DBSecurityService.java
	\| \| \|-- DBUserManager.java
	\| \| `-- entity
	\| \| \|-- GroupPeer.java
	\| \| \|-- PermissionPeer.java
	\| \| \|-- RolePeer.java
	\| \| \|-- RolePermissionPeer.java
	\| \| \|-- SecurityObject.java
	\| \| \|-- TurbineGroup.java
	\| \| \|-- TurbinePermission.java
	\| \| \|-- TurbineRole.java
	\| \| \|-- TurbineUser.java
	\| \| \|-- TurbineUserPeer.java
	\| \| \|-- UserGroupRolePeer.java
	\| \| `-- UserPeer.java
	\| \|-- ldap
	\| \| \|-- LDAPSecurityConstants.java
	\| \| \|-- LDAPSecurityService.java
	\| \| \|-- LDAPUser.java
	\| \| \|-- LDAPUserManager.java
	\| \| `-- util
	\| \| `-- ParseExceptionMessage.java
	\| `-- passive
	\| `-- PassiveUserManager.java
	`-- util
	\|-- AccessControlException.java
	\|-- AccessControlList.java
	\|-- DataBackendException.java
	\|-- EntityExistsException.java
	\|-- GroupSet.java
	\|-- PasswordMismatchException.java
	\|-- PermissionSet.java
	\|-- RoleSet.java
	\|-- TurbineSecurityException.java
	`-- UnknownEntityException.java

	]]></source>

	</section>

	</body>
	</document>