アプリケーションの必要性に応じて、ログインしたユーザ、或は特定のロールを有するユーザに対してのみページ閲覧や操作の実行を許可したい場合のような、単純なセキュリティ機能が必要な場合には、「単純なモード」で十分でしょう。 このモデルでは、設定が簡単であることや、必要なライブラリが少なくメモリの消費量も少ないメリットがあります。

一方、複雑なビジネスルールや、コンテクストの状態によるセキュリティのチェックが必要となる場合には、「より高度なモード」を使う必要があるでしょう。

単純な認証機構ではSeamアプリケーションのコンポーネントに認証を委ねるSeamLoginModule (これは、Seamに内蔵されているJAASのログインモジュールです) を使います。 このログインモジュールはSeamのデフォルトのアプリケーションポリシーとして予め設定されていますので、新たに設定に追加する事なく使用することでき、作成されているアプリケーションのエンティティクラスを利用して、認証メソッドを記述することができます。 この「単純な認証機構」を利用するためにはcomponents.xmlに下記のようにidentityコンポーネントを設定する必要があります。

<components xmlns="http://jboss.com/products/seam/components"
            xmlns:core="http://jboss.com/products/seam/core"
            xmlns:security="http://jboss.com/products/seam/security"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation=
                "http://jboss.com/products/seam/core http://jboss.com/products/seam/core-1.2.xsd 
                 http://jboss.com/products/seam/components http://jboss.com/products/seam/components-1.2.xsd
                 http://jboss.com/products/seam/drools http://jboss.com/products/seam/drools-1.2.xsd"
                 http://jboss.com/products/seam/security http://jboss.com/products/seam/security-1.2.xsd">                
        
    <security:identity authenticate-method="#{authenticator.authenticate}"/>
    
</components>

ルールに基づく承認のような、「より高度なセキュリティ機構」を実装す場合には、Drools (JBoss Rules) のjarファイル群をクラスパスに含め、後述のようにコンフィグレーションファイルに若干の設定を加えることが必要となります。

EL式 #{authenticator.authenticate} はauthenticatorコンポーネントのauthenticateメソッドを使って、ユーザの認証を行うことを示しています。

components.xml中で、identityに特定されている (紐付けされている) authenticate-methodはSeamLoginModuleがユーザの認証をするときに使用するメソッドを規定します。このメソッドはパラメータをとらず、認証の可否を示すブール値を返すよう期待されています。ユーザのusernameやpasswordは其々、Identity.instance().getUsername() とIdentity.instance().getPassword()で取得することができます。 また、ユーザが属するロールについてはIdentity.instance().addRole()により、付与することができます。 下に、Java Beanコンポーネント中の認証メソッドの完全な例を示します。

@Name("authenticator")
public class Authenticator {
   @In EntityManager entityManager;
   
   public boolean authenticate() {
      try
      {
         User user = (User) entityManager.createQuery(
            "from User where username = :username and password = :password")
            .setParameter("username", Identity.instance().getUsername())
            .setParameter("password", Identity.instance().getPassword())
            .getSingleResult();

         if (user.getRoles() != null)
         {
            for (UserRole mr : user.getRoles())
               Identity.instance().addRole(mr.getName());
         }

         return true;
      }
      catch (NoResultException ex)
      {
         FacesMessages.instance().add("Invalid username/password");
         return false;
      }
      
   }
   
}

上記の例では、UserとUserRoleはアプリケーション独自のエンティティビーンとなっています。 パラメータ roles は "admin", "user" の様に文字列として、Setに追加されてゆく必要があります。 この例の場合、userが見付からずにNoResultExceptionが投げられた場合には、認証メソッドはfalseを返して、認証が失敗したことを示します。

Identityコンポーネントはusernameとpasswordプロパティを提供することにより、ほとんどの認証プロセスに対応することができます。 これらのプロパティはログインフォームのusernameとpasswordのフィールドに直接バインドすることができますので、これらのプロパティがセットされた後にidentity.login()メソッドを呼び出すことにより、設計者が組み込んだ認証システムに基ずきユーザの認証をすることができます。 簡単なログインフォームの例を示します。

<div>
    <h:outputLabel for="name" value="Username"/>
    <h:inputText id="name" value="#{identity.username}"/>
</div>

<div>
    <h:outputLabel for="password" value="Password"/>
    <h:inputSecret id="password" value="#{identity.password}"/>
</div>

<div>
    <h:commandButton value="Login" action="#{identity.login}"/>
</div>

同様にログアウトも、#{identity.logout}を呼び出すことにより実行されます。ログアウトを実行することにより、現在まで認証されていたユーザのセキュリティの状態は破棄されます。

まとめとして、認証システムを設定するためには、以下の３つのステップが必要となります。

セキュリティエラーが出た場合にユーザがデフォルトのエラーページを見ることのない様 pages.xmlを設定して、もう少しましなセキュリティエラーページにリダイレクトすることが推奨されます。 セキュリティAPIが投げる主だった例外には下の２種類があります。

NotLoggedInExceptionが投げられた場合には、ユーザはログインページ或は登録ページにリダイレクトされる事が推奨されます。 一方、AuthorizationExceptionが投げられた場合には、 エラーページにリダイレクトされた方が良いでしょう。 これらのセキュリティエラーに対応するリダイレクトを記述したpages.xmlの例を以下に示します。

<pages>

    ...
    
    <exception class="org.jboss.seam.security.NotLoggedInException">
        <redirect view-id="/login.xhtml">
            <message>You must be logged in to perform this action</message>
        </redirect>
    </exception>
    
    <exception class="org.jboss.seam.security.AuthorizationException">
        <end-conversation/>
        <redirect view-id="/security_error.xhtml">
            <message>You do not have the necessary security privileges to perform this action.</message>
        </redirect>
    </exception>
  
</pages>

ほとんどのwebアプリケーションでは、より洗練されたログインリダイレクトを必要としますが、Seamではこの様なケースに対応出来るような機能も持たせています。

以下のようにして、 認証されていないユーザが特定のビュー (或はワイルドカードで指定されたビュー) の閲覧をしようとした時に、 Seam がユーザをログイン画面にリダイレクトするようにすることができます。

<pages login-view-id="/login.xhtml">

    <page view-id="/members/*" login-required="true"/>
    
    ...
    
</pages>

(これは、前項までの例外処理に比べて少々ぶっきらぼうさを抑えた処理ですが、例外処理によるリダイレクトと組み合わせて使用すると良いでしょう)

ユーザがログインした後で、再度ログインし直したい場合に自動的に最初のページ (ユーザが入ってきたページ) 戻したいような状況を考えてみましょう。 下の様にevent listenerをcomponents.xmlに記述すると、ログインせずに制限されたページの閲覧した (閲覧に失敗した) ことを記憶させておいて、ユーザが再ログインして成功したときに、当初の要求時のページパラメータを基に当該ページにリダイレクトさせることができます。

<event type="org.jboss.seam.notLoggedIn">
    <action expression="#{redirect.captureCurrentView}"/>
</event>
    
<event type="org.jboss.seam.postAuthenticate">
    <action expression="#{redirect.returnToCapturedView}"/>
</event>

ログインリダイレクトは対話スコープの中で実装されていますので、当該の対話スコープをauthenticate()メソッドで終了させないように注意してください。

ここでは、より高度なセキュリティ要求に答えられる、セキュリティAPIで提供されている更に高度な機能について紹介します。

<security:identity authenticate-method="#{authenticator.authenticate}" 
                      jaas-config-name="other"/>

Seamの提供するセキュリティAPIによる認可のメカニズムは、ロールと許可の組み合わせに基づいてユーザに認可を与えるというコンセプトに基づいて作られています。 ロールとは、ユーザの属するgroupあるいはtypeを意味し、そこに属していることにより、アプリケーション中で特定の操作をすることが認められます。 それに対し、パーミッション (許可) とは特定の一つの操作を、時には１回だけ、許可される事を意味します。 勿論、パーミッションだけを使って、アプリケーションを組むことは可能ですが、ロールはユーザの特定のグループに対する特権を、より簡単に、高次元のレベルで与えることができます。

ロールとは単純に、admin、userとかcustomer といったような名前で与えられます。 一方、パーミッションは、名前と操作の組み合わせで与えられ、ここの説明ではname:action (例えば、customer:delete, customer.insert) といった形式で表現しています。

それでは、@Restrictアノテーションを使った、簡単なコンポーネントのセキュリティから始めましょう。

@Name("account")
public class AccountAction {
    @Restrict public void delete() {
      ...
    }
}

@Restrict @Name("account")
public class AccountAction {
    public void insert() {
      ...
    }
    @Restrict("#{s:hasRole('admin')}") 
    public void delete() {
      ...
    }
}

@Name("account")
public class AccountAction {
    @In Account selectedAccount;
    @Restrict("#{s:hasPermission('account','modify',selectedAccount)}")
    public void modify() {
        selectedAccount.modify();
    }
}

public void deleteCustomer() {
    Identity.instance().checkRestriction("#{s:hasPermission('customer','delete',selectedCustomer)}");
}

if (!Identity.instance().hasRole("admin"))
     throw new AuthorizationException("Must be admin to perform this action");

if (!Identity.instance().hasPermission("customer", "create", null))
     throw new AuthorizationException("You may not create new customers");

うまくデザインされたユーザインターフェースでは、当該ユーザが利用する権限を持たない物は見せないようにします。 Seamのセキュリティ機構は、コンポーネントのセキュリティで使用したのと同様のEL式を使って、ページの部分あるいは個別の操作について、表示/非表示をコントロールすることができます。

インターフェースのセキュリティの例についてみてみましょう。 まず、ユーザがログインしていない場合に限ってログイン画面が表示される場合を考えてみます。 identity.isLoggedIn()プロパティを使って、下のように記述することができます。

<h:form class="loginForm" rendered="#{not identity.loggedIn}">

もし、ユーザがログインしていなければログインフォームが描画されます。 それでは、managerのロールを持つユーザに対してのみ操作が認められている項目を含むようなメニューの場合を考えてみましょう。 (マネージャー以外にはその項目が表示されないことが必要) この様な場合、下のように記述することができます。

<h:outputLink action="#{reports.listManagerReports}" rendered="#{s:hasRole('manager')}">
    Manager Reports
</h:outputLink>

これも、大変シンプルで、ユーザがmanagerロールを持っていなければ、outputLinkは描画されません。rendered属性は一般に制御そのものに使われたり、<s:div> や <s:span>の中で制御の目的に使われます。

さて、それではもう少し複雑な例として、h:dataTableで、ユーザの権限によりアクションリンクの表示、非表示を管理したい場合を考えてみましょう。 EL関数、s:hasPermissionはオブジェクトをパラメータとして受け付ける機能を持っており、それにより特定のオブジェクトに対するユーザの権限を評価することが可能となります。 下に、dataTableに対し保護されたリンクを設定する例を示します。

<h:dataTable value="#{clients}" var="cl">
    <h:column>
        <f:facet name="header">Name</f:facet>
        #{cl.name}
    </h:column>
    <h:column>
        <f:facet name="header">City</f:facet>
        #{cl.city}
    </h:column>   
    <h:column>
        <f:facet name="header">Action</f:facet>
        <s:link value="Modify Client" action="#{clientAction.modify}"
                rendered="#{s:hasPermission('client','modify',cl)"/>
        <s:link value="Delete Client" action="#{clientAction.delete}"
                rendered="#{s:hasPermission('client','delete',cl)"/>
    </h:column>
</h:dataTable>

ページ単位のセキュリティのコントロールはアプリケーションがpages.xmlを利用していないと使えませんが、設定は非常に簡単です。 pages.xml中で、セキュリティを確保したいpageエレメントに対し<restrict/><restrict></restrict>要素を加えるだけです。 restrict要素に対し値が与えられていない場合には、{viewId}:render がデフォルトとして評価され、アクセスの可否を決定します。 値が与えれれた場合には、通常のセキュリティの評価と同様に評価されます。下に、いくつかの例を示します。

<page view-id="/settings.xhtml">
    <restrict/>
</page>
        
<page view-id="/reports.xhtml">    
    <restrict>#{s:hasRole('admin')}</restrict>
</page>

上の１番目の例では、/settings.xhtml:renderという暗黙の制約がかけられており、また、２番目の例ではユーザがadminのロールに属するか否かのチェックが行われています。

Seamのセキュリティは、エンティティ単位でのread,insert,update及びdelete操作に対してのセキュリティ制約をかけることを可能にしています。

エンティティクラスのアクション全部に対してセキュリティをかけたいのであれば、下のようにクラスに@Restrictアノテーションを付記します。

@Entity
@Name("customer")
@Restrict
public class Customer {
  ...
}

もし、@Restrictが評価式無しで付記されていれば、デフォルトとしてentityName:actionがチェックされます。ここで、entityNameは当該エンティティの名前 (あるいは@Entityアノテーションがなければ、クラスの名前) で、action は read, insert, update あるいは deleteのいずれかです。

また、下のようにエンティティのライフサイクルに@Restrict アノテーションを付記することにより、特定の操作だけに制約を課すことが出来ます。

以下に、あるエンティティへの全てのinsert操作に対してセキュリティチェックを実行する為の設定の例を示します。この例では、セキュリティについて「どのようにアノテーションを付記するのか」を示しているだけですので、メソッドは何もしていない事に留意してください。

  @PrePersist @Restrict
  public void prePersist() {}      
   

ここでは、seamspaceサンプルコードから、認証されたユーザが新規のMemberBlogを挿入することが許可されているのか、をチェックするエンティティパーミッションルールの例を見てみます。 セキュリティチェックの対象となるエンティティ (この例の場合) MemberBlogが自動的にワーキングメモリにアサートされます。

rule InsertMemberBlog
  no-loop
  activation-group "permissions"  
when
  check: PermissionCheck(name == "memberBlog", action == "insert", granted == false)
  Principal(principalName : name)
  MemberBlog(member : member -> (member.getUsername().equals(principalName)))
then
  check.grant();
end;

このルールではPrincipalで示される認証されているユーザが、ブログのエントリを作成したメンバーと同じ名前であれば、memberBlog:insertのパーミッションを与えます。"name : name"という構造は、Principalファクトやそのほかの所でも見られる変数結合で、name変数にPrincipalのnameプロパティを結合します。 変数結合は、次の行の、メンバーのusernameとPrincipalの比較 (マッチング) の様な所で、値を参照することを可能にします。 詳細については、JBoss Rules のドキュメンテーションを参照してください。

最後に、JPAプロバイダーをSeamセキュリティと統合するために、リスナークラスをインストールします。

<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
                 version="1.0">
                 
    <persistence-unit-metadata>
        <persistence-unit-defaults>
            <entity-listeners>
                <entity-listener class="org.jboss.seam.security.EntitySecurityListener"/>
            </entity-listeners>
        </persistence-unit-defaults>
    </persistence-unit-metadata>
    
</entity-mappings>

特定のユーザがcustomer:modifyのパーミッションを持っているのか否か、セキュリティAPIはどのようにして知るのでしょうか？ SeamのセキュリティはJBoss Ruleに基づいた大変ユニークな方法で、ユーザのパーミッションを決定しています。 ルールエンジンを使うことのメリットは、１) 個々のユーザのパーミッションを決定しているビジネスロジックを集中管理することが出来る、２) 複雑な条件の基においてもJBossRuleは効率的にスピーディに処理することが出来る、事にあります。

Seamセキュリティはパーミッションのチェックに使用するためのsecurityRulesと呼ばれるRuleBaseを検索して使用します。 このファイルはcomponents.xmlに下のように記述、設定します。

<components xmlns="http://jboss.com/products/seam/components"
            xmlns:core="http://jboss.com/products/seam/core"
            xmlns:security="http://jboss.com/products/seam/security"
            xmlns:drools="http://jboss.com/products/seam/drools"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation=
                "http://jboss.com/products/seam/core http://jboss.com/products/seam/core-1.2.xsd 
                 http://jboss.com/products/seam/components http://jboss.com/products/seam/components-1.2.xsd
                 http://jboss.com/products/seam/drools http://jboss.com/products/seam/drools-1.2.xsd"
                 http://jboss.com/products/seam/security http://jboss.com/products/seam/security-1.2.xsd">                 
        
   <drools:rule-base name="securityRules">
       <drools:rule-files>
           <value>/META-INF/security.drl</value>
       </drools:rule-files>
   </drools:rule-base>    
   
</components>

RuleBaseが設定できましたら、セキュリティルールの記述に進みましょう。

まづ、アプリケーションの/META-INFの下にsecurity.drlというファイルを作成してください。 実際には、このファイル名はsecurity.drlである必要は無く、components.xmlの記述と一致していれば、何でもかまいません。

次に設定ファイルの内容について。この時点では、JBoss Ruleのドキュメントから拝借してくるのが手っ取り早いでしょうが、ここでは、下の様な最も単純な例から始めてみましょう。

package MyApplicationPermissions;

import org.jboss.seam.security.PermissionCheck;
import org.jboss.seam.security.Role;

rule CanUserDeleteCustomers
when
  c: PermissionCheck(name == "customer", action == "delete")
  Role(name == "admin")
then
  c.grant();
end;

このサンプルについて一行づつ見てゆきましょう。 まず、パッケージ宣言。JBossRuleのパッケージはルールの集まりで、ルールベース以外の所には関係してきませんので、どのようなパッケージ名であってもかまいません。

次に、PermissionCheckとRoleクラスのインポートで、これらは、ルールエンジンに対して、ルールの中でこれらのクラスを参照することを表わしています。

そして、ルールの記述コード。其々のルールは、ルールごとにユニークな名前が与えられている必要があります (通常は、ルールの目的をルールの名前にします。) この例の場合、CanUserDeleteCustomersがルールの名前で、読んで字の如く、顧客レコードの削除を出来るか出来ないかのチェックに使用します。

ルールの記述が２つの部分から成っている事がわかります。ルールは左部分 (LHS) と右部分 (RHS) として知られている部分から成り立っています。LHSは条件 (即ち、この条件を満たしていれば、、、) を規定しています。 LHSはwhenで表されるセクションにあり、また、RHSはLHSが満たされた場合に実行されるアクション、あるいは結果を記述しています。 RHSはthen以降の部分に記述します。 また、ルールの最後はend;で終了します。

ルールのLHS部分を見てみると、二つの条件が記述されています。 まづ、最初の部分について詳細に見てみましょう。

c: PermissionCheck(name == "customer", action == "delete")

この条件は、ワーキングメモリ中でnameプロパティがcustomerであり、actionプロパティがdeleteであるPermissionCheckオブジェクトが存在していなければならない事を示しています。 ワーキングメモリとは、セッションスコープのオブジェクトで、ルールエンジンがパーミッションチェックをするために必要なコンテキスト情報を所有している物の事を言います。hasPermission()メソッドが呼ばれる度にPermissionCheckオブジェクト、 あるいは Fact がワーキングメモリ中に保持されます。 このPermissionCheckはチェックされるパーミッションに完全に対応します。 即ち、haPermission("account", "create", null)が呼ばれると、パーミッションのチェックが終了するまでの間、nameがaccountでactionがcreateであるPermissionCheckオブジェクトがワーキングメモリに保持されます。

ワーキングメモリには、パーミッションチェックが実行される間保持されるPermissionCheck以外に、認証されたユーザが存在する間、存在する小さなオブジェクトがあります。これらには、認証プロセスで生成されたjava.security.Principalや、当該ユーザが属するロールについてのorg.jboss.seam.security.Role (複数) があります。 また、パラメータとしてIdentity.instance().getSecurityContext().assertObject()にオブジェクトを渡すことにより、他のオブジェクトをワーキングメモリ中に保持することもできます。

先の例に戻り、LHSがc:で始まっていることに気がつくと思います。 これは、変数結合を表しており、条件のマッチングに利用されるオブジェクトへの参照を意味しています。 LHSの２行目には下の記述があります。

Role(name == "admin")

これは、単純にワーキングメモリ中のRoleオブジェクトにadminという名前のnameがなければならない事を示しています。 先に述べたように、ユーザのロールはワーキングメモリ中に保持されています。 従って、これらの条件を合わせると「貴方が、adminロールのメンバーで、且つcustomer:deleteについての許可を持っているかチェックします」と言っていることになります。

そして、ルールが適用された結果を、ルールのRHSの部分に見てゆきましょう。

c.grant()

RHSはJavaコードから成っており、この例の場合はcというオブジェクト (既に述べたように、PermissionCheckオブジェクトへの変数結合) のgrant()メソッドが起動されます。PermissionCheckオブジェクトのnameとactionプロパティ以外にfalseに初期設定されたgrantedプロパティが存在します。PermissionCheckのgrant()を呼ぶことにより、grantedプロパティはtrueにセットされ、パーミッションのチェックが成功し、ユーザはパーミッションで決められたアクションについて実行することが出来るようになります。

rule CanDoAnythingToCustomersIfYouAreAnAdmin
when
  c: PermissionCheck(name == "customer")
  Role(name == "admin")
then
  c.grant();
end;        
        

キャプチャを起動して走らせる為には、Seamの Resourece Servlet を下のように、web.xmlに設定する必要があります。これにより、アプリケーションのページにキャプチャチャレンジのイメージを提供するようになります。

<servlet>
    <servlet-name>Seam Resource Servlet</servlet-name>
    <servlet-class>org.jboss.seam.servlet.ResourceServlet</servlet-class>
</servlet>
    
<servlet-mapping>
    <servlet-name>Seam Resource Servlet</servlet-name>
    <url-pattern>/seam/resource/*</url-pattern>
</servlet-mapping>

ページにキャプチャチャレンジを追加するのはいたって簡単です。 Seamはcaptchaというページスコープのコンポーネントを提供しており、キャプチャのバリデーションを含むキャプチャ処理に必要な全ての機能を提供しています。

<div>
    <h:graphicImage value="/seam/resource/captcha?#{captcha.id}"/>
</div>
  
<div>
    <h:outputLabel for="verifyCaptcha">Enter the above letters</h:outputLabel>
    <h:inputText id="verifyCaptcha" value="#{captcha.response}" required="true"/>
    <div class="validationError"><h:message for="verifyCaptcha"/></div>
</div>

上の様に設定することにより、graphicImageがキャプチャチャレンジの表示をコントロールし、inputTextがユーザからの回答を受け取り、フォームが送信された時に自動的にキャプチャと照合されます。