セキュリティ・サービス / Security Service

  • UserManager should become a service in it's own right.

    UserManager は自身の正しさをもってしてサービスとなるべきです。

  • 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.

    ACL メカニズムは交換可能となるべきです。新たなインターフェースである ACLBuilder は定義を行われ、'Object buildACL(User)'の単一の方法 - メソッドを 持っています。 UserManagerService にはACLBuilder を実装する *サービス名* プロパティがあります。 BuildACL はクラスメソッドではなくインスタンスとなり、サービスの固定したインスタンスは 考案される必要があります。

  • 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)

    ユーザオブジェクトには、 代わる代わるに代理として設定された ACLBuilder の役目をして UserManagerService の代理を行う Object getACL() メソッドがあります。 ACLBuilder はACL オブジェクトへの参照を内部的に保持しており、 実行環境上のセキュリティ情報の変更を反映することが出来るので、 返却されたオブジェクトをキャッシュすることが出来ます。

  • TurbineSecurityService will be the default ACLBuilder shipped with the system.

    TurbineSecurityService はシステムとともにリリースされるデフォルトの ACLBuilder になります。

  • TurbineSecurityService should have it's OM/Peer classes Torque generated.

    TurbineSecurityService は Torque によって生成された OM / Peer クラスを持つ必要があります。

  • Group should be could be renamed to 'Realm' or 'Domain'. This should decrease the confusion about it's meaning.

    グループは「レルム」か「ドメイン」にリネームされるべきです。 これは本来の意味の混乱を避けるためです。

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

    ロール／グループ／パーミッションの属性は失われます。 私は理解されているアイデアについて考えているわけではありません。

  • 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

    ユーザ属性はメタ情報をストアするためには、分離されたひとつのテーブルや２つのテーブルにもなります。 これはユーザオブジェクトのためにカスタマイズされた Peer クラスを必要とします。 最近の Torque の２レベルのクラス生成では、これは簡単になっています。

  • 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.

    バインドされないイベントのセッションにおいては、カウンタやタイムスタンプの接近のみが アップデートされます。すべてのデータではありません。 これは特定されたセッションの問題により管理者が行った変更のオーバーライドに対する修正を行います。 アップデートされる必要がある属性情報は、ユーザ属性メタ情報テーブルに置かれる必要があります。

  • All references to peers have to be removed from the interfaces. Anything peer specific must be pushed down into DBSecurityService.

    Peer に対するすべての参照はインターフェースより削除を行われます。 すべての Peer 特性は DBSecurityService に挿入する必要があります。

  • 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.

    直列に実行を行うためには、多重のセキュリティサービス実装を許容してください。 これは LDAP セキュリティサービスで制御されるサイトと DB セキュリティサービスによって制御されるその他一部のサイトを許容します。

  • 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.

    すべてのセキュリティコードは同一にグループ化されるべきです。 現時点においては散在しており、むしろ混乱しています。 ユーティリティコードはセキュリティサービスパッケージに移動し、 DBSecurityService の OM / Peer は残りの DBSecurityService コードに パッケージされました。 ここに私は新たなレイアウトを提案します。 これは多くのクラスの位置の非推奨であるものを必要としますが、 理解に達するために多くの助けとなるものです。 

.
|-- 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