WebLogic セキュリティ プロバイダの開発

認可プロバイダ

認可とは、ユーザの ID などの情報に基づいて、ユーザと WebLogic リソースとの対話を管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Server では、認可プロバイダはユーザと WebLogic リソースとの対話を制限して、整合性、機密性、および可用性を確保します。

以下の節では、認可プロバイダの概念と機能、およびカスタム認可プロバイダの開発手順について説明します。

認可の概念

認可プロバイダを開発する前に、以下の概念を理解しておく必要があります。

アクセス決定

認証プロバイダの LoginModule と同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作を WebLogic リソースに対して実行するパーミッションをサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答を PERMIT、DENY、または ABSTAIN のいずれかで返します。

Java Authorization Contract for Containers の使用

Java Authorization Contract for Containers (JACC) は Java EE の一部です。JACC は、EJB およびサーブレットに対するパーミッションベースのセキュリティ モデルです。JACC は、JSR-115 によって定義されます。

JACC は、WebLogic Server ドメイン内の EJB およびサーブレット コンテナに代替認可メカニズムを提供します。JACC がコンフィグレーションされている場合、WebLogic Security フレームワークのアクセス決定、裁決、およびロール マッピング機能は、EJB およびサーブレットの認可判定には使用されません。

WebLogic Server は、JSR-115 に完全に準拠しているものの、WebLogic 認証プロバイダほどには最適化されていない JACC プロバイダを実装します。Java JACC クラスは、アクセス決定を下す際に使用します。JSR-115 はロール マッピングに対処する方法を定義しないので、ロールとプリンシパルの間のマッピングには WebLogic JACC クラスが使用されます。JACC プロバイダの開発の詳細については、http://java.sun.com/javaee/5/docs/api/javax/security/jacc/package-frame.html を参照してください。

認可プロセス

図 7-1 に、認可プロセスにおける認可プロバイダ (および関連する裁決プロバイダとロール マッピング プロバイダ) と WebLogic Security フレームワークとの対話を示し、続いてこの図について説明します。

一般に、認可は以下のように実行されます。

カスタム認可プロバイダを開発する必要があるか

WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 認可プロバイダが含まれています。WebLogic 認可プロバイダは、このバージョンの WebLogic Server の認可機能をデフォルトで適用するものです。WebLogic 認可プロバイダは、特定のユーザが保護対象の WebLogic リソースへのアクセスを許可されているかどうかを判定するためのポリシーベースの認可エンジンを使用して、アクセス決定を返します。また、WebLogic 認可プロバイダは、システム内のセキュリティ ポリシーのデプロイメントとアンデプロイメントもサポートしています。自社の既存の認可メカニズムを使用する場合は、カスタム認可プロバイダを作成してそれを既存のメカニズムに結合できます。

カスタム認可プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

セキュリティ レルムのすべての認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール マッピング、または資格マッピング用にカスタム セキュリティ プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションの SSPI を実装する必要があります。

カスタム認可プロバイダの開発方法

WebLogic 認可プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム認可プロバイダを開発することができます。

適切な SSPI による実行時クラスの作成

実行時クラスを作成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダの実行時クラスを作成します。

カスタム認可プロバイダの実行時クラスの作成例については、「例 : サンプル認可プロバイダの実行時クラスを作成する」を参照してください。

AuthorizationProvider SSPI を実装する

AuthorizationProvider SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を用意する必要があります。

getAccessDecision

AuthorizationProvider SSPI と getAccessDecision メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。

DeployableAuthorizationProviderV2 SSPI を実装する

DeployableAuthorizationProviderV2 SSPI を実装するには、「「Provider」SSPI の目的について」および「AuthorizationProvider SSPI を実装する」で説明されているメソッドと以下のメソッドの実装を用意する必要があります。

deleteApplicationPolicies

deployExcludedPolicy

deployPolicy

deployUncheckedPolicy

endDeployPolicies

startDeployPolicies

undeployAllPolicies

DeployableAuthorizationProviderV2 SSPI と deployPolicy および undeployPolicy メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。

ApplicationInfo インタフェース

ApplicationInfo インタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ プロバイダに渡します。このデータを使用すると、アプリケーションをユニークに識別できます。

WebLogic Security フレームワークは、ユーザの利便を図るために ApplicationInfo インタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。

DeployableAuthorizationProviderV2 インタフェースと DeployableRoleProviderV2 インタフェースは ApplicationInfo を使用します。たとえば、DeployableAuthorizationProviderV2 メソッドの実装を例に挙げます。WebLogic Security フレームワークは、DeployableAuthorizationProviderV2 の startDeployPolicies メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。ApplicationInfo データは、アプリケーションのデプロイ時に Administration Console で提供される情報を基に決められます。

startDeployPolicies メソッドは、他の DeployableAuthorizationProviderV2 メソッドでこの後使用できる DeployPolicyHandle を返します。

ApplicationInfo インタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentType クラスの定義に従って、APPLICATION、CONTROL_RESOURCE、EJB、または WEBAPP のいずれかです。

次のコードは、このタスクを実行する方法の一例です。

public DeployPolicyHandle startDeployPolicies(ApplicationInfo appInfo)

throws DeployHandleCreationException

:

// アプリケーション情報を取得する

String appId = appInfo.getApplicationIdentifier();

ComponentType compType = appInfo.getComponentType();

String compName = appInfo.getComponentName();

WebLogic Security フレームワークは、DeployableAuthorizationProviderV2 の deleteApplicationPolicies メソッドを呼び出し、このアプリケーションの ApplicationInfo インタフェースを渡します。deleteApplicationPolicies メソッドは、アプリケーションのポリシーをすべて削除します。このメソッドは、アプリケーションが削除されたときに WebLogic Server ドメイン内の管理サーバでのみ呼び出されます。

AccessDecision SSPI を実装する

AccessDecision SSPI を実装する際には、以下のメソッドの実装を用意する必要があります。

isAccessAllowed

isProtectedResource

AccessDecision SSPI と isAccessAllowed および isProtectedResource メソッドの詳細については、WebLogic Server API リファレンス Javadoc を参照してください。

レルム アダプタ認証プロバイダと互換性のあるカスタム認可プロバイダを開発する

認証プロバイダは、サブジェクト内へのユーザおよびグループの格納を担当するセキュリティ プロバイダです。ユーザおよびグループはその後、認可プロバイダなど、他のタイプのセキュリティ プロバイダによって、サブジェクトから抽出されます。セキュリティ レルム内でコンフィグレーションされた認証プロバイダがレルム アダプタ認証プロバイダである場合、ユーザおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザおよびグループの情報もまた、少し異なる方法で抽出する必要があります。

コード リスト 7-1 は、サブジェクトへの格納にレルム アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザ名またはグループ名に一致するかどうかをチェックするために、カスタム認可プロバイダで使用できるコードです。このコードは、isAccessAllowed メソッドと isProtectedResource メソッドの双方に属しています。

/** 
 * サブジェクトがユーザ/グループ名に一致するかどうかを判断する
 * 
 * @param principalWant このロール内のプリンシパルの名前を含む文字列
 * (ロール定義)
 * 
 * @param subject リソースにアクセスしようとしているユーザおよび 
 * ユーザのグループを識別するプリンシパルを含むサブジェクト
 * 
 * @return 現在のサブジェクトがロール内のプリンシパル名に一致していれば true、
 * それ以外の場合は false の boolean
 */ 
private boolean subjectMatches(String principalWant, Subject subject) 
{ 
   // 最初に、グループ名の一致かどうかを確認 
   if (SubjectUtils.isUserInGroup(subject, principalWant)) { 
      return true; 
   } 
   // 2 番目に、ユーザ名の一致かどうかを確認 
   if (principalWant.equals(SubjectUtils.getUsername(subject))) { 
      return true; 
   } 
   // 一致せず
   return false; 
}

例 : サンプル認可プロバイダの実行時クラスを作成する

コード リスト 7-2 は、サンプル認可プロバイダの実行時クラスである SampleAuthorizationProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。

package examples.security.providers.authorization.simple;

import java.security.Principal;
import java.util.Date;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.SubjectUtils;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AccessDecision;
import weblogic.security.spi.ApplicationInfo;
import weblogic.security.spi.ApplicationInfo.ComponentType;
import weblogic.security.spi.DeployableAuthorizationProviderV2;
import weblogic.security.spi.DeployPolicyHandle;
import weblogic.security.spi.Direction;
import weblogic.security.spi.InvalidPrincipalException;
import weblogic.security.spi.Resource;
import weblogic.security.spi.Result;
import weblogic.security.spi.SecurityServices;
import weblogic.security.spi.VersionableApplicationProvider;

public final class SimpleSampleAuthorizationProviderImpl implements DeployableAuthorizationProviderV2, AccessDecision, VersionableApplicationProvider
{
   private static String[] NO_ACCESS = new String[0];
   private static String[] ALL_ACCESS = new String[] {WLSPrincipals.getEveryoneGroupname()};
   private String description;
   private SimpleSampleAuthorizerDatabase database;

   public void initialize(ProviderMBean mbean, SecurityServices services)
   {
      System.out.println("SimpleSampleAuthorizationProviderImpl.initialize");
      SimpleSampleAuthorizerMBean myMBean = (SimpleSampleAuthorizerMBean)mbean;
      description = myMBean.getDescription() + "\n" + myMBean.getVersion();
      database = new SimpleSampleAuthorizerDatabase(myMBean);
   }

   public String getDescription()
   {
      return description;
   }

   public void shutdown()
   {
      System.out.println("SampleAuthorizationProviderImpl.shutdown");
   }

   public AccessDecision getAccessDecision()
   {
      return this;
   }

   public Result isAccessAllowed(Subject subject, Map roles, Resource resource, 
   ContextHandler handler, Direction direction) 
   {
      System.out.println("SimpleSampleAuthorizationProviderImpl.isAccessAllowed");
      System.out.println("\tsubject\t= " + subject);
      System.out.println("\troles\t= " + roles);
      System.out.println("\tresource\t= " + resource);
      System.out.println("\tdirection\t= " + direction);

      Set principals = subject.getPrincipals();

      for (Resource res = resource; res != null; res = res.getParentResource()) {
         if (database.policyExists(res)) {
            Result result = isAccessAllowed(res, subject, roles);
            System.out.println("\tallowed\t= " + result);
            return result;
         }
      }
      Result result = Result.ABSTAIN;
      System.out.println("\tallowed\t= " + result);
      return result;
   }

   public boolean isProtectedResource(Subject subject, Resource resource) throws 
   InvalidPrincipalException 
   {
      System.out.println("SimpleSampleAuthorizationProviderImpl.
        isProtectedResource");
      System.out.println("\tsubject\t= " + subject);
      System.out.println("\tresource\t= " + resource);

      for (Resource res = resource; res != null; res = res.getParentResource()) {
         if (database.policyExists(res)) {
            System.out.println("\tprotected\t= true");
            return true;
         }
      }
      System.out.println("\tprotected\t= false");
      return false;
   }

public DeployPolicyHandle startDeployPolicies(ApplicationInfo application)
{
   String appId = application.getApplicationIdentifier();
   String compName = application.getComponentName();
   ComponentType compType = application.getComponentType();
   DeployPolicyHandle handle = new    SampleDeployPolicyHandle(appId,compName,compType);

   database.removePoliciesForComponent(appId, compName, compType);
   return handle;

  public void deployPolicy(DeployPolicyHandle handle,
Resource resource, String[] roleNamesAllowed)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.deployPolicy");
   System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
   System.out.println("\tresource\t= " + resource);
   for (int i = 0; roleNamesAllowed != null && i < roleNamesAllowed.length; i++) {
     System.out.println("\troleNamesAllowed[" + i + "]\t= " + roleNamesAllowed[i]);
}
database.setPolicy(resource, roleNamesAllowed);
}

   public void deployUncheckedPolicy(DeployPolicyHandle handle, Resource resource)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.deployUncheckedPolicy");
   System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
   System.out.println("\tresource\t= " + resource);
   database.setPolicy(resource, ALL_ACCESS);
}

public void deployExcludedPolicy(DeployPolicyHandle handle, Resource resource)

  {
   System.out.println("SimpleSampleAuthorizationProviderImpl.deployExcludedPolicy");
   System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
   System.out.println("\tresource\t= " + resource);
   database.setPolicy(resource, NO_ACCESS);
}

public void endDeployPolicies(DeployPolicyHandle handle)
{
   database.savePolicies();
}

public void undeployAllPolicies(DeployPolicyHandle handle)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.undeployAllPolicies");
   SampleDeployPolicyHandle myHandle = (SampleDeployPolicyHandle)handle;
   System.out.println("\thandle\t= " + myHandle.toString());

   // ポリシーを削除する
   database.removePoliciesForComponent(myHandle.getApplication(),
                                       myHandle.getComponent(),
                                       myHandle.getComponentType());
}

public void deleteApplicationPolicies(ApplicationInfo application)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationPolicies");
   String appId = application.getApplicationIdentifier();
   System.out.println("\tapplication identifier\t= " + appId);

   // アプリケーションのポリシーを削除する
   database.removePoliciesForApplication(appId);
}

private boolean rolesOrSubjectContains(Map roles, Subject subject, String roleOrPrincipalWant)
{
   // 最初に、ロール名の一致かどうかを確認する
if (roles.containsKey(roleOrPrincipalWant)) {
     return true;
}

   // 2 番目に、グループ名の一致かどうかを確認する
   if (SubjectUtils.isUserInGroup(subject, roleOrPrincipalWant)) {
     return true;
   }

   // 3 番目に、ユーザ名の一致かどうかを確認する
   if (roleOrPrincipalWant.equals(SubjectUtils.getUsername(subject))) {
     return true;
   }

   // 一致せず
   return false;
}

private Result isAccessAllowed(Resource resource, Subject subject, Map roles)
{
   // データベース内のこのリソースへのアクセスが許可されているプリンシパルとロールを繰り返しループする
   for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();) {
     String roleOrPrincipalAllowed = (String)e.nextElement();
     if (rolesOrSubjectContains(roles, subject, roleOrPrincipalAllowed)) {
       return Result.PERMIT;
     }
   }
   // リソースが明示的に言及され、アクセスを不許可
   return Result.DENY;
}

public void createApplicationVersion(String appId, String sourceAppId)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.createApplicationVersion");
   System.out.println("\tapplication identifier\t= " + appId);
   System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));

   // 既存のアプリケーションを指定したときに新しいポリシーを作成する
   if (sourceAppId != null) {
     database.clonePoliciesForApplication(sourceAppId,appId);
   }

}

public void deleteApplicationVersion(String appId)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion");
   System.out.println("\tapplication identifier\t= " + appId);

   // アプリケーションのポリシーを削除する
   database.removePoliciesForApplication(appId);
}

public void deleteApplication(String appName)
{
   System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication");
   System.out.println("\tapplication name\t= " + appName);

   // アプリケーションのポリシーを削除する
   database.removePoliciesForApplication(appName);
}

class SampleDeployPolicyHandle implements DeployPolicyHandle
{
   Date date;
   String application;
   String component;
   ComponentType componentType;

   SampleDeployPolicyHandle(String app, String comp, ComponentType type)
{
     this.application = app;
     this.component = comp;
     this.componentType = type;
     this.date = new Date();
}

     public String getApplication() { return application; }
     public String getComponent() { return component; }
     public ComponentType getComponentType() { return componentType; }

     public String toString()
     {
       String name = component;
       if (componentType == ComponentType.APPLICATION)
          name = application;
       return componentType +" "+ name +" ["+ date.toString() +"]";
     }
   }
}

ポリシー コンシューマ SSPI

WebLogic Server には、JMX (MBean) デフォルト ポリシーと Web サービス アノテーション用のポリシー コンシューマが実装されています。このリリースの WebLogic Server には、認可プロバイダがポリシー コレクションを取得するために使用できる SSPI があります。

PolicyConsumer SSPI は省略可能です。ポリシー コレクションを消費するためには、この SSPI を実装する認可プロバイダのみが呼び出されます。

この SSPI では、初期状態のポリシー コレクションの配信と、更新後のポリシー コレクションの配信の両方がサポートされます。

ポリシー コレクションの消費においては、PolicyConsumer SSPI をサポートするすべての認可プロバイダが呼び出されます。各認可プロバイダは、特定のポリシー セットのポリシー コレクションを取得するかしないかを選択できます。プロバイダでポリシーが永続化される場合、ポリシーを取得する必要があるのは一度だけです。一方、プロバイダでポリシーがメモリに保持される場合、ポリシー コレクションを再び取得することも可能です。

用意されている WebLogic Server 認可プロバイダでは、ポリシーは LDAP 内に永続化されます。

必要な SSPI インタフェース

カスタム認可プロバイダでポリシー コレクションの配信をサポートするには、以下の 3 つのインタフェースを実装する必要があります。

これらのインタフェースについては、これ以降の節で説明します。

PolicyConsumerFactory SSPI インタフェースを実装する

認可プロバイダには、PolicyConsumer のインスタンスを WebLogic Security フレームワークで使用できるように、PolicyConsumerFactory インタフェースが実装されています。WebLogic Security フレームワークでは PolicyConsumerFactory の実装を呼び出して、プロバイダのポリシー コンシューマの実装を取得します。

PolicyConsumerFactory SSPI にはメソッドが 1 つあり、このメソッドは PolicyConsumer SSPI インタフェースの実装を返します。

public interface PolicyConsumerFactory

{
/**
* PolicyConsumer セキュリティ サービス プロバイダ インタフェース (SSPI) の
* 実装を取得する
*
* @return PolicyConsumer SSPI の実装
*/
public PolicyConsumer getPolicyConsumer();
}

PolicyConsumer SSPI インタフェースを実装する

PolicyConsumer SSPI は、ポリシー コレクションを消費するためのポリシー コレクション ハンドラを返します。これには getPolicyCollectionHandler() というメソッドが 1 つあり、このメソッドは引数に PolicyCollectionInfo の実装を取って、PolicyCollectionHandler インタフェースの実装を返します。

public interface PolicyConsumer

  {
    /**
     * ポリシー セットを消費するためのポリシー ハンドラを取得する
     *
     * @param info ポリシー セットの PolicyCollectionInfo
     *
     * @return PolicyCollectionHandler または NULL。NULL はポリシー セットが
     *     不要であることを示す
     *
     * @exception ConsumptionException ハンドラの取得中にエラーが発生して
     *     ポリシー セットを消費できない場合に送出
     */
public PolicyCollectionHandler getPolicyCollectionHandler(
           PolicyCollectionInfo info)
    throws ConsumptionException;
}

WebLogic Security フレームワークでは getPolicyCollectionHandler() メソッドを呼び出して、ポリシー コレクションに関するデータを PolicyCollectionInfo インタフェースの実装としてセキュリティ プロバイダに渡します (このインタフェースはあらかじめ実装されているので、ユーザが実装する必要はありません)。

PolicyCollectionInfo の getName()、getVersion()、getTimestamp()、および getResourceTypes() メソッドを使用して、このポリシー セットに関する情報を検索します。検索後には PolicyCollectionHandler を返すか、ポリシー コレクションが不要であることを示す NULL を返します。

public interface PolicyCollectionInfo

{
/**
 * コレクションの名前を取得する
 */
public String getName();

/**
 * ポリシーの実行時バージョンを取得する
 */
public String getVersion();


/**
 * ポリシーのタイムスタンプを取得する
 */
public String getTimestamp();


/**
 * ポリシー コレクションで使用されるリソース タイプを取得する
 */
public Resource[] getResouceTypes();
}


PolicyCollectionHandler SSPI インタフェースを実装する

PolicyConsumer.getPolicyCollectionHandler() メソッドは PolicyCollectionHandler インタフェースの実装を返します。PolicyCollectionHandler には setPolicy、setUncheckedPolicy、および done() という 3 つのメソッドがあります。setPolicy() はリソースおよびロールの名前を取り、ロールに基づいてポリシーを設定します。setUncheckedPolicy() メソッドはすべてのユーザにアクセスを許可します。

done() メソッドはポリシー コレクションの完了を示します。done() メソッドでは、ポリシー セットの古いポリシーをすべて削除することをお勧めします。

public interface PolicyCollectionHandler

{
     /**
      * 指定したリソースにポリシーを設定する
      */
     public void setPolicy(Resource resource, String[] roleNames)
        throws ConsumptionException;

     /**
      * アクセスを常に許可するポリシーを設定する
      */
     public void setUncheckedPolicy(Resource resource)
        throws ConsumptionException;

     /**
      * ポリシー コレクションの完了を示す
      */
     public void done()
       throws ConsumptionException;

}

更新後のポリシー コレクションをサポートする

更新後のポリシー コレクションの配信をサポートするには、PolicyConsumer SSPI をサポートするすべての認可プロバイダで PolicyConsumer.getPolicyCollectionHandler() メソッドに渡された PolicyCollectionInfo の内容を調べて、ポリシー セットが変更されているかどうかを判断する必要があります。各プロバイダでは、初期状態のポリシー コレクションと SSPI の外部から受け取ったカスタマイズ後のポリシーとの衝突を解決する方法を (できればコンフィグレーションによって) 決定しておくことが必要です。

WebLogic Server で提供されている認可プロバイダでは、カスタマイズ後のポリシーが更新後のポリシー コレクションで置き換えられません。初期状態のポリシー コレクションのポリシーはすべて削除され、カスタマイズ後のポリシーと更新後のポリシー コレクションのみが有効になります。ポリシー コレクションの情報に異なるタイムスタンプやバージョンがある場合、更新後のポリシー コレクションとして扱われます。コレクションの名前は永続キーとして使用されます。

PolicyConsumerMBean

ポリシー コンシューマ SSPI を実装する認可プロバイダには、そのプロバイダでポリシーの消費をサポートすることを示すために weblogic.management.security.authorization.PolicyConsumerMBean も実装する必要があります。

PolicyStoreMBean

このリリースの WebLogic Server では、weblogic.management.security.authorization.PolicyStoreMBean という新しい MBean がサポートされています。この MBean は、管理者が生成した XACML ポリシーおよびポリシー セットの標準的な管理操作 (追加、削除、取得、リスト表示、変更、読み込み) に使用できます。認可プロバイダ MBean やロール マッピング プロバイダ MBean には、必要に応じてこの MBean インタフェースを実装できます。

セキュリティ管理者は、PolicyStoreMBean のメソッドを使用して、サーバ内のポリシーを XACML ドキュメントとして管理できます。たとえば、デフォルトの XACML プロバイダを使用するドメインを作成および管理したり、作成済みの XACML ドキュメントを管理したりできます。これらの XACML ポリシーは、WebLogic Server では WLST を使用して管理できます。

WebLogic Server にはこの MBean の実装が含まれており、付属の XACML プロバイダで使用できます。また、この MBean の独自の実装を記述して、カスタムの認可プロバイダやロール マッピング プロバイダで使用することも可能です。WebLogic Server に用意されている XACML プロバイダでは、XACML 2.0 のコア仕様に記載されている XACML の必須機能がサポートされています。Oracle 固有の使用方法については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。

ポリシーは XACML 2.0 のポリシーまたは PolicySet ドキュメントで表現されます。カスタム認可プロバイダでは、XACML 2.0 のコア仕様に記載されている標準の Policy または PolicySet ドキュメントを想定する必要があります。カスタム ロール マッピング プロバイダでは、『Core and hierarchical role based access control (RBAC) profile of XACML v2.0』に記載されているロール割り当てポリシーと整合性がある Policy または PolicySet ドキュメントを想定する必要があります。

具体的には、Target に以下を含める必要があります。

XACML Policy ファイルの形式を調べる

XACML 2.0 のコア仕様と、『ロールおよびポリシーによる WebLogic リソースの保護』で説明している Oracle 拡張が、提供されている XACML 認可プロバイダおよびロール マッピング プロバイダで使用する XACML ポリシー ファイルについての最も確実な情報です。

ただしサポートされている XACML ファイルの形式を開発プロセスの一環として確認する場合は、おそらく、Administration Console を使用して、XACML 認可またはロール マッピング プロバイダのデータベースからデータを XACML ファイルとしてエクスポートする方法が最も便利です。エクスポートした XACML ファイルをコピーして別の名前で保存し、任意のツールで確認します。

WLST を使用して PolicyStoreMBean にポリシーを追加する

コード リスト 7-3 に、WLST を使用して XACML ファイルから PolicyStoreMBean のインスタンスに 1 つのポリシーを追加する例を示します。

この例ではこのスクリプトで使用するプロパティを、次の ant スクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<property name="xacml-docs-dir" value="${xacmldir}/xacml-docs"/>
<sysproperty key="file" value="${xacml-docs-dir}/policy-getSubject.xacml"/>

:

try:

      protocol = System.getProperty("protocol")
      host = System.getProperty("host")
      user = System.getProperty("authuser")
      passwd = System.getProperty("authpwd")
      port = System.getProperty("port")
      dom = System.getProperty("domain")
      rlm = System.getProperty("realm")
      fil = System.getProperty("file")
      prov = System.getProperty("provider")
      stat = System.getProperty("status")

def configure():
try:
      url = protocol + "://" + host + ":" + port
      connect(user,passwd, url)
      path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
      print("cd'ing to " + path)
      cd(path)
      print("calling open()")
      xacmlFile = open(fil,"r")
      print("calling read()")
      xacmlDoc = xacmlFile.read()
      print("calling cmo.addPolicy")
      if stat == "none":
          cmo.addPolicy(xacmlDoc)
      else:
          cmo.addPolicy(xacmlDoc, stat)
      print("Add error handling")
:
:

『WebLogic Scripting Tool ガイド』の「MBean の移動と照会」で説明しているように、WLST が初めて WebLogic Server インスタンスに接続すると、変数 cmo (現在の管理オブジェクト) がすべてのコンフィグレーション管理オブジェクトのルート DomainMBean に初期化されます。MBean タイプに移動すると、SecurityConfigurationMBean の場合、cmo の値は SecurityConfigurationMBean を反映したものになります。MBean インスタンス、つまりこの場合には PolicyStoreMBean を実装する認可プロバイダ MBean (例では変数 prov で識別) に移動するときには、WLST によって cmo の値が現在の MBean インスタンスに変更されます。

この例では PolicyStoreMBean の addPolicy() メソッドを使用して、XACML ファイルからポリシー ストアに読み込まれるポリシーを追加しています。addPolicy() メソッドの 2 つのバリアント (ステータスを伴うものと伴わないもの) が示されています。

ステータスを指定しない addPolicy() メソッドを使用する場合、デフォルトで ACTIVE に設定されます。これは、ポリシーがその対象で適用されるどのような決定でも評価されることを示します。ステータスは明示的に ACTIVE、INACTIVE、または BYREFERENCE に設定できます。INACTIVE ステータスは、ポリシーが評価されずに格納されるだけであることを示します。BYREFERENCE ステータスは、評価されるポリシー セットによって参照された場合にだけ、ポリシーが評価されることを示します。

このタイプの WLST スクリプトは、次のような方法でコマンドラインから呼び出せます。

java -Dhost="localhost " -Dprotocol="t3" -Dauthuser="weblogic"
-Dauthpwd="weblogic" -Dport="7001" -Ddomain="mydomain" -Drealm="myrealm"
-Dprovider="Authorizers/XACMLAuthorizer"
-Dfile="C:/XACML/xacml-docs/policy12.xml" -Dstatus="none" weblogic.WLST
XACML/scripts/XACMLaddPolicy.py

WLST を使用して PolicySet を String として読み込む

コード リスト 7-4 に、WLST を使用して PolicySet を String として読み込む例を示します。

この例ではこのスクリプトで使用するプロパティを、次の ant スクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<sysproperty key="identifier" value="urn:sample:xacml:2.0:wlssecqa:resource:type@E@Fejb@G@M@Oapplication@ENoD
DRolesOrPoliciesEar@M@Omodule@Eejb11inEarMiniAppBean.jar@M@Oejb@EMiniAppBean@
M@Omethod@EgetSubject@M@OmethodInterface@ERemote"/>
<sysproperty key="version" value="1.0"/>

:
:
try:

      print("start XACMLreadPolicySet.py")
      protocol = System.getProperty("protocol")
      host = System.getProperty("host")
      user = System.getProperty("authuser")
      passwd = System.getProperty("authpwd")
      port = System.getProperty("port")
      dom = System.getProperty("domain")
      rlm = System.getProperty("realm")
      prov = System.getProperty("provider")
      id = System.getProperty("identifier")
      vers = System.getProperty("version")

:
:
def configure():

try:

      url = protocol + "://" + host + ":" + port
      connect(user,passwd, url)
      path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
      print("cd'ing to " + path)
      cd(path)
      polset = cmo.readPolicySetAsString(id, vers)
      print("readPolicySetAsString() returned the following policy set: " + polset)
      print"Add error handling."
:
:

XACML 2.0 のコア仕様で説明されているように、<PolicySet> 要素には <Policy> のセットまたは別の <PolicySet> 要素、およびそれらの評価結果を結合するための指定された手順が含まれます。詳細については XACML 2.0 のコア仕様を参照してください。

バルク認可プロバイダ

WebLogic Server のこのリリースには、以下に示すバルク アクセス バージョンの認可プロバイダ SSPI インタフェースがあります。

バルク アクセス SSPI インタフェースを使用すると、認可プロバイダにおいて 1 回の呼び出しで複数の判定要求を取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。バルク SSPI バリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡された Resource オブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

バルク バージョンでない SSPI インタフェースとバルク バージョンの SSPI インタフェースの使用方法には若干の違いがあります。

BulkAccessDecision.isAccessAllowed() メソッドではロールの Map を引数に取ります。これは、第 1 に Resource オブジェクト、続いてロール名 (Map<Resource、Map<String、SecurityRole>> roles) で索引付けされ、サブジェクトに関連付けられているもので、認可判定時に考慮に入れる必要があります。

BulkAccessDecision.isAccessAllowed() メソッドは Map (Resource、結果で索引付け) を返します。これは、リソースに定義された認可ポリシーが、要求されたメソッドの実行を許可するかどうかを示します。

WebLogic MBeanMaker による MBean タイプの生成

カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダの MBean タイプを作成します。

MBean 定義ファイル (MDF) を作成する

MBean 定義ファイル (MDF) を作成するには、次の手順に従います。

WebLogic MBeanMaker を使用して MBean タイプを生成する

MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。

MBean タイプの作成手順は、カスタム認可プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

任意 SSPI MBean とカスタム操作を追加しない場合

カスタム認可プロバイダの MDF に任意 SSPI MBean もカスタム操作も実装しない場合、次の手順を行います。

任意 SSPI MBean またはカスタム操作を追加する場合

カスタム認可プロバイダの MDF に任意 SSPI MBean またはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

生成される MBean インタフェース ファイルについて

MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的について」で説明されているように、これは initialize メソッドで使用するのが一般的です。

WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で SampleAuthorizer MDF を実行すると、結果として SampleAuthorizerMBean.java という MBean インタフェース ファイルが生成されます。

WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) を作成する

WebLogic MBeanMaker を使用して MDF を実行して中間ファイルを生成し、MBean 実装ファイルを編集してその中に適切なメソッドの実装を記述したら、カスタム認可プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。

カスタム認可プロバイダの MJF を作成するには、次の手順に従います。

生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。

WebLogic Server 環境に MBean タイプをインストールする

MBean タイプを WebLogic Server 環境にインストールするには、MJF を WL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。このインストール コマンドによって、カスタム認可プロバイダが「デプロイ」されます。つまり、カスタム認可プロバイダを WebLogic Server Administration Console から管理できるようになります。

カスタム認可プロバイダをコンフィグレーションすることによって (「Administration Console によるカスタム認可プロバイダのコンフィグレーション」を参照)、MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。

Administration Console によるカスタム認可プロバイダのコンフィグレーション

カスタム認可プロバイダをコンフィグレーションするということは、認可サービスを必要とするアプリケーションがアクセス可能なセキュリティ レルムにカスタム認可プロバイダを追加するということです。

カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム認可プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。

認可プロバイダとデプロイメント記述子を管理する

エンタープライズ JavaBean (EJB) や Web アプリケーションなどのアプリケーションの中には、Java EE の関連デプロイメント情報と WebLogic Server デプロイメント記述子を格納するものがあります。Web アプリケーションの場合、デプロイメント記述子ファイル (web.xml と weblogic.xml) には、セキュリティ ポリシーの宣言を含む Java EE セキュリティ モデルの実装情報が記述されます。この情報は、WebLogic Server Administration Console で認可プロバイダを初めてコンフィグレーションするときに格納するのが一般的です。

Java EE プラットフォームはデプロイメント記述子で Web アプリケーションおよび EJB のセキュリティを標準化しているので、WebLogic Server ではこの標準メカニズムが WebLogic Security サービスに統合され、Web アプリケーションおよび EJB リソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも Administration Console のみを使用することもできます。また、状況によっては、この 2 つの方法を組み合わせることもできます。

選択した方法によって、セキュリティ モデルを適用する必要もあります。WebLogic では、個々のデプロイメントについて複数のセキュリティ モデルがサポートされ、使用する方法を組み込むレルム全体のコンフィグレーションについてはセキュリティ モデルがサポートされます。

デプロイメント記述子を使用するようにコンフィグレーションすると、web.xml および weblogic.xml デプロイメント記述子ファイルからセキュリティ ポリシー情報が読み込まれます (web.xml ファイルと weblogic.xml ファイルの例については、コード リスト 7-5 とコード リスト 7-6 を参照)。この情報は、認可プロバイダのセキュリティ プロバイダ データベースにコピーされます。

<web-app> 

   <welcome-file-list> 
      <welcome-file>welcome.jsp</welcome-file> 
   </welcome-file-list> 

   <security-constraint> 
      <web-resource-collection>
         <web-resource-name>Success</web-resource-name>
         <url-pattern>/welcome.jsp</url-pattern>
         <http-method>GET</http-method> 
         <http-method>POST</http-method> 
      </web-resource-collection> 
      <auth-constraint> 
         <role-name>developers</role-name> 
      </auth-constraint> 
   </security-constraint> 

   <login-config> 
       <auth-method>BASIC</auth-method> 
       <realm-name>default</realm-name> 
   </login-config> 

   <security-role> 
      <role-name>developers</role-name> 
   </security-role> 

</web-app>

<weblogic-web-app> 
   <security-role-assignment> 
      <role-name>developers</role-name>
      <principal-name>myGroup</principal-name> 
   </security-role-assignment> 
</weblogic-web-app>

セキュリティ ポリシー デプロイメントを有効にする

カスタム認可プロバイダの開発の一環として DeployableAuthorizationProviderV2 SSPI を実装し、カスタム認可プロバイダでデプロイ可能なセキュリティ ポリシーをサポートする場合、カスタム認可プロバイダのコンフィグレーション担当者 (つまり、開発者または管理者) は、WebLogic Server Administration Console で [ポリシー デプロイメントを有効化] チェック ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、認可プロバイダは「オフ」と見なされます。このため、複数の認可プロバイダがコンフィグレーションされている場合、[ポリシー デプロイメントを有効化] チェック ボックスを使用して、セキュリティ ポリシーのデプロイメントに使用する認可プロバイダを指定できます。

セキュリティ ポリシーを管理するためのメカニズムの提供

WebLogic Server Administration Console を使用してカスタム認可プロバイダをコンフィグレーションすると、必要な認可サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ プロバイダに関連付けられたセキュリティ ポリシーを管理する方法を管理者にも提供する必要があります。たとえば WebLogic 認可プロバイダには、ポリシー エディタ ページが管理者向けに用意されており、さまざまな WebLogic リソースのセキュリティ ポリシーを追加、変更、または削除することができます。

カスタム認可プロバイダを開発している場合、管理者はポリシー エディタ ページも認可サービスへのアクセスも利用できません。したがって、セキュリティ ポリシーを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム認可プロバイダのデータベースのセキュリティ ポリシー データ (つまり式) を読み書きできなければなりません。

それには、以下の 3 通りの方法があります。

オプション 1 : セキュリティ ポリシー管理用のスタンドアロン ツールを開発する

WebLogic Server Administration Console とまったく別のツールを開発する場合には、この方法を選択します。

この方法では、カスタム認可プロバイダ向けにコンソール拡張を作成する必要も、管理 MBean を開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。

オプション 2 : 既存のセキュリティ ポリシー管理ツールを Administration Console に統合する

WebLogic Server Administration Console とは別のツールを持っており、それを Administration Console から起動する場合には、この方法を選択します。

この方法の場合、ツールでは以下のことを行う必要があります。