第4章
この章では、exteNd DirectorのACL (アクセス制御リスト)の使用方法について説明します。この章は、次の節から構成されています。
Securityサブシステムの目的は、「権限」です。権限は、アプリケーションリソースへのアクセスを制限するプロセスです。Securityサブシステムは、標準のJ2EEセキュリティAPIに基づいて作成されています。
Securityサブシステムは、認証を行うためにDirectoryサブシステムに依存しています。つまり、Securityサブシステムでは、保護されたアプリケーションリソースへの要求は、認証されたユーザのみが行うことができると想定しています。
権限は、要求された操作を実行するための十分な許可がユーザまたはグループ(「プリンシパル」で表されます)にあることを確認してから実行されます。プリンシパルは、アクセス制御リスト(ACL)を使用して定義するか、またはセキュリティ役割を使用するリソースにマップすることができます。
役割ベースのセキュリティの詳細については、を参照してください。
ACLベースの権限は、ポートレット、ドキュメント、フォルダ、グループページ、ユーザページ、プロファイルなど、複数の展開にわたり持続するサブシステム管理機能およびアプリケーションリソースオブジェクトを保護します。
次の用語は、ACLベースの権限に対するexteNd Directorのサポートを定義しています。
|
用語 |
定義 |
|---|---|
|
ACL |
アクセス制御リスト。特定の「要素」または「要素タイプ」へのアクセスを制限するエントリのリスト。各ACLエントリで、「プリンシパル」に「権限」のセットを関連付けます。 ACLに、ACLが属する「要素」または「要素タイプ」が関連付けられていない場合、アクセスは制限されません。 |
|
要素 |
exteNd Directorサブシステムによって管理される、一意に識別される持続性リソース生成物。たとえば、Content Managementサブシステムのドキュメントおよびフォルダは要素です。exteNd Directorアプリケーションでは、セキュリティ保護が可能な要素に対して許可を設定および取得することができます。 要素は、アプリケーションサーバが有効な限り持続します。つまり、要素は、exteNd Directorプロジェクトの再展開による影響を受けません。 |
|
要素タイプ |
機能または動作が同様のオブジェクトのグループを定義するときに使用される文字列(EbiFolder、EbiDocumentなどのフレームワーク要素)。ACLは、要素タイプ、および個々の要素に適用できます。 Securityサブシステムは、別のサブシステムに対する組み込み要素タイプのセットを備えています。各要素タイプには、その要素がサポートする許可のリストがあります。 |
|
プリンシパル |
認証されたユーザ、グループ、またはコンテナ。exteNd Directorでは、プリンシパルは、Java 2標準インタフェースであるjava.security.Principalを継承するクラスとして実装されています。 |
|
許可 |
「要素」exteNd Directorへのアクセスのタイプには、次の組み込み許可のセットがあります。CREATE、DELETE、EXECUTE、LIST、PROTECT、PUBLISH、READ、SELECT、UPDATE、およびWRITEです。 組み込み許可は、ハードコードされているので、Security APIを使用して変更することはできません。 注記: 負の許可は、exteNd Directorではサポートされていません。 各ACLサブシステムは、これらの組み込み許可のサブセットを使用します。各許可は、サブシステムごとに異なる意味を持つ場合があります。
|
exteNd Directorでは、プリンシパルは、Java 2標準インタフェースjava.security.Principalを継承するクラスとして実装されています。「プリンシパル」を使用して、個人、会社、およびログインIDなどの任意をエンティティを表すことができます。
exteNd Directorでは、次の3つのタイプのプリンシパルが定義されています。
「コンテナ」 - eDirectoryなどのLDAPベースのディレクトリサービス内の組織単位。このプリンシパルを使用すると、ユーザコンテナにACLを設定してセキュリティを継承できます。コンテナのACLへのアクセスを参照してください。
プリンシパルは、Directory APIでは、com.sssw.fw.directory.apiパッケージのインタフェースとして表されます。
public interface EbiRealmUser extends Principal public interface EbiRealmGroup extends Group public interface EbiRealmContainer extends Principal
プリンシパルインタフェースのインスタンスをコードで直接生成するか、または次に示すAPIメソッドの1つを使用することができます。
ユーザが要素にアクセスするたびに、Securityサブシステムは、指定されたアクションを実行する許可がそのユーザにあるかどうかをチェックします。要素にACLがある場合、exteNd Directorは、指定した許可がユーザに与えられているかどうかをチェックします。
|
状況 |
アクセスの結果 |
|---|---|
|
オブジェクトにACLがない。 |
アクションは続行される |
|
オブジェクトにACLはあるが、ユーザが名前またはグループで含まれていない。 |
アクセスは拒否される- EboSecurityException |
|
ユーザが、特定のタイプのアクセスに対する許可を持つLocksmithユーザまたはサブシステム管理グループのACLに記述されている(管理グループの許可により、個々の要素に対する許可は上書きされます)。
|
アクションは続行される |
|
オブジェクトに、(IDまたはグループによって)ユーザが含まれるACLがあり、ユーザは特定のタイプのアクセスに対する許可を持っている |
アクションは続行される |
|
オブジェクトに、(IDまたはグループによって)ユーザが含まれるACLがあり、ユーザは特定のタイプのアクセスを拒否されている |
アクセスは拒否される- EboSecurityException |
プロセス Securityサブシステムは、次の3つの手順で、要素にアクセスする許可がユーザにあるかどうかを判断します。
exteNd Directorには、ACLを使用して各サブシステムへの管理アクセスを定義する組み込みグループのセットがあります。Director Administration Consoleを使用して、各許可に対してユーザを追加および削除できます(を参照してください)。
各サブシステム管理者グループのアクセス権の一般的な説明は、次のとおりです。
EbiSecurityManager.setRestrictedAccess()メソッドを使用して、ポータルおよびコンテンツ管理要素へのアクセスを制限することができます。たとえば、WRITE許可に対してドキュメントフォルダへのアクセスを制限した場合、ContentAdminグループのメンバーだけが要素へのWRITEアクセスを持ちます。
注記: 制限付きアクセス権は、制限された要素に関連付けられている他のACLよりも優先されます。
EbiSecurityManagerインタフェースの関連するメソッドは次のとおりです。
|
メソッド |
返される値 |
説明 |
|---|---|---|
|
setRestrictedAccess() |
成功の場合、ブール |
要素に対する指定されたアクセスをシステム管理者に制限します。 |
|
checkRestrictedAccess() |
ブール |
要素でアクセスが制限されているかどうかをチェックします。 |
この節では、exteNd DirectorのDirectory APIおよびSecurity APIを使用する方法をいくつか示します。ACLセキュリティオブジェクトにアクセスするための主要なポイントは、次の委任インタフェースです。
委任の基礎的な情報については、『exteNd Directorアプリケーションの開発』のサブシステムサービスへのアクセスに関する節を参照してください。
DACを使用したACLへのアクセス DAC (Director Administration Console)を使用してACLにアクセスすることもできます。
次の例は、以降に説明するSecurity APIの例で使用される委任オブジェクトを取得する方法を示しています。
import com.sssw.fw.security.api.*;
// Getting delegate objects from a factory --
// must be done within a try block.
try {
// Get a metadata delegate.
EbiSecurityMetaDelegate smd = com.sssw.fw.security.client.EboFactory.getSecurityMetaDelegate();
// Get an ACL delegate.
EbiSecurityAclDelegate ad = com.sssw.fw.security.client.EboFactory.getSecurityAclDelegate();
// Use the delegate objects.
}
catch (EboFactoryException e) {
sb.append( e.getMessage() );
}
次の例は、要素タイプおよびUUIDを取得する方法を示しています。これは、他の例で使用されます。
// Get delegates. Security API委任の取得を参照してください。 // Get the element type metadata from the EbiSecurityMetaDelegate. EbiElementTypeMeta typeMeta = smd.getElementTypeMeta(context); // This example uses the PortalAdmin element. String portalSubSystem = EbiSecurityConstants.SUBSYSTEM_PORTAL_SERVICE; String adminType = typeMeta.getAdminType(portalSubSystem); String adminID = typeMeta.getAdminID(portalSubSystem);
注記: 要素タイプ名は、EbiFrameworkElementのサブインターフェイスの定数として定義されます。たとえば、Content Managementサブシステムのドキュメントは、com.sssw.cm.api.EbiDocument.EL_DOCUMENTで定義されています。
この例は、要素に付与できる許可のリストを取得する方法を示します。
// Get delegates. Security API委任の取得を参照してください。
// Get the element type. 要素タイプおよびIDの取得を参照してください。
// Get the EbiAccessRightMeta object for the element type.
EbiAccessRightMeta meta = smd.getAccessRightMeta(context,adminType);
// Retrieve the list of permissions.
String[] rights = meta.getPermissionNames();
for (int i = 0; i < rights.length; i++) {
sb.append( rights[i] );
次の例は、要素に対して特定の許可を持つプリンシパルのリストを取得する方法を示しています。この例では、PortalAdmin要素のPROTECT許可に割り当てられたプリンシパルのリストを取得します。
import java.security.*;
// Get delegates. Security API委任の取得を参照してください。
// Get the element type. 要素タイプおよびIDの取得を参照してください。
// Get the principals for a specific permission type.
Principal [] prins = null;
prins = ad.getPrincipalsFromAcl(context, adminID, adminType, EbiPermission.PROTECT);
for (int i = 0; i < prins.length; i++) {
sb.append( prins[i].toString() );
セッションコンテキストのプリンシパルにアクセスできる特定のタイプのアクセス可能リソース(要素)をすべて列挙するには、次のメソッドを使用します(EbiSecurityManagerから使用できます)。
/**
* Returns a Collection of elements accessible to the userwhose context is passed in.
* @param context context
* @param elType framework element type, tells the method which * element type to determine accessibility for
* @param rights a list of access right permissions to be * checked, e.g. EbiPermission.READ, EbiPermission.WRITE,
* EbiPermission.EXECUTE, etc.; note that if multiple * rights are specified, the method will treat the list
* as a Boolean OR and will attempt to find elements that * have either READ or WRITE or EXECUTE etc. for the user
* @return a Collection of accessible framework elements of the * specified type; the Collection is empty if no accessible
* elements of the type are found
*/
public Collection getAccessibleElements(EbiContext context, String elType, String[] rights)
throws EboUnrecoverableSystemException
次のコードは、ACLの文字列表現を取得する方法を示しています。
import java.security.*; // Get delegates. Security API委任の取得を参照してください。 // Get the element type; // 要素タイプおよびIDの取得を参照してください。 // Get the contents of the ACL in the form of a string. Acl adacl = ad.getAcl(context, adminID, adminType); String adaclcontent = adacl.toString(); sb.append( adaclcontent );
次のコードは、Admin要素のACLにプリンシパルを追加する方法を示しています。
import com.sssw.fw.directory.api.*; import java.security.*; // Get delegates.Security API委任の取得を参照してください。 // Get the element type.要素タイプおよびIDの取得を参照してください。 // Get a Directory delegate. EbiDirectoryDelegate dd = com.sssw.fw.directory.client.EboFactory.getDirectoryDelegate(); // Get a principal.Must be a valid realm user. Principal user = dd.getUser(context,"SomeUser"); // Add the principal to the ACL. Principal [] prins = new Principal[1]; prins[0] = user; ad.addPrincipalsToAcl(context, adminID, adminType, EbiPermission.PROTECT, prins); sb.append( "Added " + user.toString() + " PROTECT");
注記: 次の例では、EboFactoryExceptionの他に次の例外もコードで処理する必要があります。
catch (EboSecurityException e) {
sb.append( e.getMessage() );
}
catch (EboException e) {
sb.append( e.getMessage() );
}
プリンシパルタイプの「コンテナ」は、LDAPツリー内の組織単位を表します。コンテナプリンシパルを使用すると、LDAPディレクトリコンテナ(または、同じツリーディレクトリ構造)にACLを設定して、指定したツリー階層のすべてのユーザにACLを適用できます。この機能は、「セキュリティ継承」と呼ばれます。exteNd Directorでは、セキュリティ継承は、Novell eDirectoryのような階層型LDAPレルムに対して設定されているアプリケーションで使用できます。
ディレクトリを使用すると、次の操作を実行できます。
com.sssw.fw.directory.apiパッケージでは、次のインタフェースが提供されています。
public interface EbiTreeRealm public interface EbiRealmContainerDelegate
注記: コンテナをexteNd DirectorからLDAPレルムに追加することはできません。追加したい場合は、ネイティブLADPツールを使用します。
次のコードは、前の例(ACLへのプリンシパルの割り当て)に基づいています。このコードは、管理要素のACLにコンテナプリンシパルを追加する方法を示しています。
import com.sssw.fw.directory.api.*; import java.security.*; // Get delegates.Security API委任の取得を参照してください。 // Get the element type; // 要素タイプおよびIDの取得を参照してください。 // Get a new Container delegate. EbiRealmContainerDelegate rcd = new EbiRealmContainerDelegate(); // Get Container principal.Must be a valid realm container. Principal container = rcd.getEbiRealmContainer(context,"cn=sample,o=users"); // Add the principal to the ACL. Principal [] prins = new Principal[1]; prins[0] = container; ad.addPrincipalsToAcl(context, adminID, adminType, EbiPermission.PROTECT, prins);
注記: コンテナプリンシパルオブジェクトは、APIでアクセスすることも、Portalの共有およびグループページを制御するDAC (Director Administration Console)のセクションからアクセスすることもできます。ただし、DACを使用して、コンテナプリンシパルに管理アクセスやコンテンツ管理要素アクセスを割り当てることはできません。
ACLセキュリティをカスタマイズする方法は、3つあります。
EboSecurityManagerクラスを継承するクラスを作成して、ランタイムACL検証論理を上書きする。たとえば、PROTECT、READ、WRITEなどの別の許可を使用できるように、Locksmith ACLメタデータを変更できます。
EbiSecurityManagerを完全に再実装し、次の場所にあるservices.xmlを変更する。
XWB/DirectorTemplate/Director/library/SecurityService/ SecurityService-conf
<service>
<interface>com.sssw.fw.security.api.EbiSecurityManager
</interface>
<impl-class>com.sssw.fw.security.core.EboSecurityManager
</impl-class>
<description>Security manager that provides authentication
and permission validation
</description>
<max-instances>1</max-instances>
<startup>M</startup>
</service>
新しいサブシステムの追加は、exteNd Directorとサードパーティセキュリティサービスを統合するときに必要になる場合があります。
注記: このトピックは、このガイドの範囲外のトピックなので、ここでは手順の概要だけを示します。詳細については、Novellテクニカルサポートまでお問い合わせください。
サブシステムのメタデータ情報を既存のサブシステム要素タイプのメタデータに追加します。
com.sssw.fw.security.api.EbiElementTypeMeta, singleton
Security Meta Delegateをコールして、メタデータを完全に変更します。
com.sssw.fw.security.api.EbiSecurityMetaDelegate
管理者タイプ、およびサブシステム要素タイプのメタデータで定義されている任意の要素タイプの新しいAccess Right Metaを作成します。
「Access Right Meta」オブジェクトは、特定の要素タイプ(または管理タイプ)を許可に関連付けるためのメタデータを定義するときに使用されるAPIオブジェクトです。
com.sssw.fw.security.api.EbiAccessRightMeta
カスタムUIを作成して、Security ACL Delegateをコールすることで、新しく作成したサブシステムの管理タイプおよび要素タイプに基いてACLを設定できるようにします。
com.sssw.fw.security.api.EbiSecurityAclDelegate
Security Delegateをコールして、新しいサブシステムのランタイムACL検証ロジックを追加します。
com.sssw.fw.security.api.EbiSecurityDelegate
userHasAccessRight(context, right, adminID, adminType)
要素レベルアクセスを確認します(要素レベルアクセスがある場合)。
userHasAccessRight(context, right, elementUUID, elementType)
exteNd Directorでは、Security APIを使用して、独自のカスタム許可を定義できます。JavadocのEbiPermissionMetaを参照してください。
カスタム許可は、任意の詳細レベルのACLベース権限をアプリケーションで使用する方法を提供します。たとえば、カスタム許可のセットを作成して、各許可でアプリケーションコードの特定のメソッドにアクセスを許可することができます。
カスタム許可は、アプリケーションデータベースにXMLファイルとして保存されます。これらのXMLファイルを直接編集しないでください。変更する場合は、Security APIを使用してください。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...