Sun Java System Access Manager 7 2005Q4 管理ガイド

認証の設定

ここでは、配備の認証を設定する方法について説明します。最初の節では、デフォルトの認証モジュールタイプの概要について説明し、必要な事前の設定手順を示します。レルム、ユーザー、ロールなどに対して、同じ認証モジュールタイプの複数の設定インスタンスを設定できます。また、認証に成功するためには複数のインスタンスの条件に合格する必要があるようにするため、認証連鎖を追加することもできます。次の内容で構成されています。

認証モジュールタイプ

認証モジュールは、ユーザー ID やパスワードなどのユーザー情報を収集し、その情報をデータベース内のエントリで確認するプラグインです。ユーザーが認証条件を満たす情報を入力した場合、そのユーザーは要求するリソースへのアクセスを許可されます。ユーザーが認証条件を満たしていない情報を入力した場合、そのユーザーは要求したリソースへのアクセスを拒否されます。Access Manager は、次の 15 タイプの認証モジュールとともにインストールされます。

注 –

一部の認証モジュールタイプでは、認証インスタンスとして使用できるようにするには、事前の設定が必要です。必要に応じて、設定手順がモジュールタイプの説明にリスト表示されています。

コア

Access Manager では、コア認証モジュールばかりではなく、デフォルトで 15 種類の認証モジュールを提供しています。コア認証モジュールでは、認証モジュールの全体的な設定を行います。Active Directory 認証、匿名認証、証明書に基づく認証、HTTP 基本認証、JDBC 認証、LDAP 認証、任意の認証のモジュールを追加して有効にする前に、コア認証モジュールの追加と有効化を行う必要があります。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

「拡張プロパティー」ボタンをクリックすると、レルムに対して定義できる「コア」認証属性が表示されます。グローバル属性はレルムに適用できないので表示されません。

Active Directory

Active Directory 認証モジュールでは、LDAP モジュールと同様の認証が実行されますが、LDAP 認証モジュールの場合の Directory Server ではなく、Microsoft の Active Directory™ サーバーが使用されます。LDAP 認証モジュールを Active Directory サーバー用に設定できますが、このモジュールでは、LDAP と Active Directory 認証の両方を同一レルム下に存在させることができます。

注 –

このリリースの Active Directory 認証モジュールでは、ユーザー認証のみがサポートされます。パスワードポリシーは LDAP 認証モジュールのみでサポートされます。

匿名 (anonymous)

デフォルトでは、このモジュールを有効にすると、ユーザーは匿名ユーザーとして Access Manager にログインできるようになります。「有効な匿名ユーザー」のリスト属性を設定して、このモジュールに匿名ユーザーのリストを定義することもできます。匿名アクセスを許可するということは、パスワードなしでアクセスさせるということです。匿名アクセスは、特定の種類のアクセス (読み取りのためのアクセスや検索のためのアクセスなど)、特定のサブツリー、またはディレクトリ内の個別のエントリに制限されます。

証明書

証明書に基づく認証では、個人用デジタル証明書 (PDC) を使用してユーザーを特定し、認証します。Directory Server に格納された PDC に一致すること、また証明書失効リスト (CRL) で確認されていることを求めるように、PDC を設定できます。

証明書に基づく認証モジュールをレルムに追加する前に、行う必要のある作業があります。まず、Access Manager とともにインストールした Web コンテナを保護し、証明書に基づく認証で使用できるように設定する必要があります。証明書に基づくモジュールを有効にする前に、Web Server に対するこれらの初期設定手順について、『Sun ONE Web Server 6.1 管理者ガイド』の第 6 章「証明書と鍵の使用」を参照してください。このマニュアルは、次の場所にあります。

http://docs.sun.com/db/prod/s1websrv#hic

または、次の場所にある『Sun ONE Application Sever Administrator's Guide to Security』を参照してください。

http://docs.sun.com/db/prod/s1appsrv#hic

注 –

証明書に基づくモジュールを使用して認証されるユーザーは、ブラウザ用に PDC を要求する必要があります。使用しているブラウザによって、手順が異なります。詳細は、お使いのブラウザのマニュアルを参照してください。

このモジュールを追加するためには、Access Manager にレルム管理者としてログインし、Access Manager と Web コンテナに対して SSL を設定し、クライアント認証を有効化しておく必要があります。詳細は、第 3 章「Access Manager の SSL モードへの設定」を参照してください。

HTTP 基本

このモジュールは、HTTP プロトコルのビルトイン認証サポートである基本認証を使用します。Web サーバーはユーザー名とパスワードを求めるクライアント要求を発行し、その情報を認証済み要求の一部としてサーバーに返します。Access Manager ではユーザー名とパスワードを取得し、LDAP 認証モジュールに対してユーザーを内部的に認証します。HTTP 基本認証が正常に機能するために、LDAP 認証モジュールを追加する必要があります (HTTP 基本モジュールを単独で追加しても機能しない)。いったん認証に成功したユーザーには、再認証の際にユーザー名とパスワードの入力は要求されません。

JDBC

JDBC (Java Database Connectivity) 認証モジュールでは、JDBC 技術に対応したドライバを提供する SQL データベースを通して Access Manager でユーザーを認証できるようにするメカニズムが提供されます。SQL データベースへの接続は、JDBC ドライバを通して直接行うか、JNDI 接続プールで行います。

注 –

このモジュールは、MySQL4.0 と Oracle 8i でテストされています。

LDAP

LDAP 認証モジュールを使用すると、ユーザーがログインするときに、特定のユーザー DN およびパスワードを使用して、LDAP Directory Server にバインドする必要があります。すべてのレルムに基づく認証では、デフォルトの認証モジュールです。ユーザーが Directory Server に存在するユーザー ID およびパスワードを指定すると、ユーザーは有効な Access Manager セッションへのアクセスが許可され、セットアップされます。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

メンバーシップ

メンバーシップ認証は、my.site.com または mysun.sun.com のように、パーソナライズされたサイトのように実装されます。モジュールが有効なときに、ユーザーは管理者の支援なしでアカウントを作成し、パーソナライズします。ユーザーは作成したアカウントを使用し、追加済みユーザーとしてアクセスできます。また、ユーザーはビューアのインタフェースにアクセスできます。ビューアのインタフェースは、認証データおよびユーザー設定として、ユーザープロファイルデータベースに保存されています。

MSISDN

MSISDN (Mobile Station Integrated Services Digital Network) 認証モジュールでは、携帯電話などのデバイスに関連するモバイル加入者 ISDN を使用して認証できます。これは対話型モジュールではありません。このモジュールでは加入者 ISDN が取得されて Directory Server で妥当性が検査され、番号が一致するユーザーが検索されます。

RADIUS

Access Manager は、すでにインストールされている RADIUS サーバーと連携するように設定できます。エンタープライズで認証のために旧バージョンの RADIUS サーバーを使用している場合に便利です。RADIUS 認証モジュールを有効にするには、次の 2 つの手順を行います。

RADIUS サーバーを設定します。

詳しい手順については、RADIUS サーバーのマニュアルを参照してください。
RADIUS 認証モジュールを登録し、有効にします。

Sun Java System Application Server で RADIUS を設定する

RADUIS クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。RADUIS 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)
connect (接続)
listen (待機)
resolve (解決)

ソケット接続のアクセス権を与えるには、Application Server の server.policy ファイルにエントリを追加します。SocketPermission は、ホストの指定と、そのホストへの接続方法を指定する一連のアクションとで構成されます。ホストは次のように指定されます。

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

ホストは、DNS 名または IP アドレスの数値で表されるか、ローカルマシンの場合は localhost と表されます。DNS 名でホストを指定する場合は、ワイルドカード "*" を 1 つだけ使用できます。ワイルドカードを使用する場合は、*.example.com のように、左端に置く必要があります。

ポート (またはポート範囲) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

listen アクションは、ローカルホストで使用される場合のみ有効です。resolve (ホスト/IP 解決のネームサービスルックアップ) アクションは、ほかの任意のアクションが存在する場合に暗黙的に使用されます。

たとえば、SocketPermission を作成するときに次のアクセス権をコードに与えると、そのコードは machine1.example.com のポート 1645 に接続でき、またそのポート上で接続を受け入れることができます。

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

同様に、次のアクセス権を与えられたコードは、ローカルホストのポート 1024 〜 65535 に接続することと、これらのポートで接続受け入れおよび待機を行うことができます。

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。

SafeWord

Secure Computing の SafeWord™ または SafeWord PremierAccessd™ 認証サーバーに対して送られる SafeWord 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SafeWord 認証のクライアント部分を担当します。SafeWord サーバーは、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。

Sun Java System Application Server で SafeWord を設定する

SafeWord クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。SafeWord 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)
connect (接続)
listen (待機)
resolve (解決)

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

ポート (portrange) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

SAML

SAML (Security Assertion Markup Language) 認証モジュールでは、ターゲットサーバーで SAML アサーションの受信と確認が行われます。このモジュールが、Access Manager 2005Q1 から Access Manager 2005Q4 などのアップグレード後も含めて、ターゲットマシンで設定されている場合にかぎって、SAML SSO は動作します。

SecurID

RSA の ACE/Server 認証サーバーに対して送られる SecurID 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SecurID 認証のクライアント部分を担当します。ACE/Server は、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

SecurID 認証では、認証ヘルパー amsecuridd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amsecuridd プロセスは root ユーザーとして実行する必要があります。amsecuridd ヘルパーについては、第 20 章「amsecuridd ヘルパー」を参照してください。

注 –

このリリースの Access Manager の場合、Linux プラットフォームと Solaris x86 プラットフォームでは SecurID 認証モジュールを使用できません。この 2 つのプラットフォームでは、SecurID 認証モジュールの登録、設定、有効化を行わないでください。SecurID 認証モジュールは、SPARC のみで使用できます。

UNIX

Access Manager がインストールされている Solaris または Linux システムで既知の UNIX ユーザー ID およびパスワードに対する認証要求を処理するように、Access Manager を設定できます。UNIX 認証ではレルム属性は 1 つだけしかなく、またグローバル属性は少ししかありませんが、システムの観点から検討すべき点があります。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

UNIX 認証では、認証ヘルパー amunixd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。UNIX ヘルパーは Access Manager ごとに 1 つだけあり、そのすべてのレルムで共用されます。

Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amunixd プロセスは root ユーザーとして実行する必要があります。UNIX 認証モジュールは、UNIX 認証要求を待機するために localhost:58946 へのソケットを開くことで、amunixd デーモンを呼び出します。デフォルトのポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd

デフォルト以外のポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd [-c portnm] [ipaddress]

ipaddress と portnumber は、AMConfig.properties 内の UnixHelper.ipadrs 属性 (IPV4 形式) と UnixHelper.port 属性で指定されています。amunixd を amserver コマンド行ユーティリティーから実行することもできます。amserver は AMConfig.properties からポート番号と IP アドレスを取り出し、このプロセスを自動的に実行します。

/etc/nsswitch.conf ファイル内の passwd エントリでは、/etc/passwd および /etc/shadow ファイル、または NIS を認証で探すかどうかを指定します。

Windows デスクトップ SSO

Windows デスクトップ SSO 認証モジュールは、Windows 2000™ に使用する、Kerberos ベースのプラグインモジュールです。このサービスを使用すると、Kerberos Distribution Center (KDC) で認証されたユーザーは、ログインの条件を再度提示しなくても Access Manager に認証されます (シングルサインオン)。

ユーザーは、SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) プロトコルで Access Manager に Kerberos トークンを送信します。この認証モジュールで Access Manager への Kerberos ベースのシングルサインオンを実行するには、ユーザーが、クライアントサイドにおいて、SPNEGO プロトコルをサポートして自分自身を認証する必要があります。一般的に、このプロトコルをサポートするすべてのユーザーは、このモジュールを使用して Access Manager に認証できます。クライアントサイドでトークンを使用できるかどうかにより、SPENGO トークンか Kerberos トークンがこのモジュールによって提供されます。どちらの場合でもプロトコルは同一です。Microsoft Windows 2000 以上で動作している Microsoft Internet Explorer 5.01 以上では、現在このプロトコルがサポートされています。Solaris 9 および 10 の Mozilla 1.4 では SPNEGO がサポートされますが、Solaris では SPNEGO がサポートされていないので、返されるトークンは KERBEROS トークンのみです。

注 –

Kerberos V5 認証モジュールの新機能を使用するには、JDK 1.4 以上を使用する必要があります。この SPNEGO モジュールで Kerberos ベースの SSO を実行するには、Java GSS API を使用する必要があります。

Internet Explorer の既知の制限事項

WindowsDesktopSSO 認証に Microsoft Internet Explorer 6.x を使用しており、WindowsDesktopSSO モジュールで設定されている KDC レルムと一致する、ユーザーの Kerberos/SPNEGO トークンにこのブラウザでアクセスできない場合、WindowsDesktopSSO モジュールへの認証がエラーになったあとで、このブラウザはその他のモジュールに対して不正に動作します。この問題の直接的な原因は、Internet Explorer が WindowsDesktopSSO モジュールでエラーになると、ブラウザを再起動するまで、コールバックを要求されても、別のモジュールのコールバックを Access Manager に渡すことができなくなることです。このため、WindowsDesktopSSO のあとのすべてのモジュールは、ユーザー資格が NULL であるためにエラーとなります。

関連情報については、次の資料を参照してください。

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Windows デスクトップ SSO の設定

Windows デスクトップ SSO 認証を有効にするプロセスには、次の 2 つの段階があります。

Windows 2000 のドメインコントローラにユーザーを作成します。
Internet Explorer をセットアップします。

Windows 2000 のドメインコントローラにユーザーを作成する

手順

ドメインコントローラで、Access Manager 認証モジュール用のユーザーアカウントを作成します。
1. 「スタート」メニューから、「プログラム」>「管理ツール」に進みます。
2. 「Active Directory ユーザーとコンピュータ」を選択します。
3. Access Manager ホスト名をユーザー ID (ログイン名) として新しいユーザーを作成します。Access Manager ホスト名には、ドメイン名を含めないでください。

ユーザーアカウントをサービスプロバイダの名前と関連付け、Keytab ファイルを Access Manager がインストールされたシステムにエクスポートします。そのためには、次のコマンドを実行します。

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName-out hostname
.HTTP.keytab

ktpass コマンドには、次のパラメータを使用できます。

hostname: Access Manager が稼働する、ドメイン名なしのホスト名です。

domainname: Access Manager のドメイン名です。

DCDOMAIN: ドメインコントローラのドメイン名です。この名前は、Access Manager のドメイン名とは異なる場合があります。

password: ユーザーアカウントのパスワードです。ktpass はパスワードを検証しないので、パスワードが正しいことを確認してください。

userName: ユーザーアカウント ID です。これはホスト名と同じにする必要があります。

注 –

両方の Keytab ファイルがセキュリティー保護されているようにします。

サービステンプレートの値は、次の例のようになっている必要があります。

「サービス主体」: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

「Keytab ファイル名」: /tmp/machine1.HTTP.keytab

「Kerberos レルム」: ISQA.EXAMPLE.COM

「Kerberos サーバー名」: machine2.EXAMPLE.com

「ドメイン名を含む主体を返す」: false

「認証レベル」: 22

サーバーを再起動します。

Internet Explorer をセットアップする

この手順は、Microsoft Internet Explorer™ 6 以上に当てはまります。これよりも前のバージョンを使用している場合は、Access Manager がブラウザのインターネットゾーンにあり、ネイティブ Windows 認証が有効であることを確認します。

手順

「ツール」メニューで、「インターネットオプション」>「詳細設定」>「セキュリティー」に進みます。

「統合 Windows 認証を使用する」オプションを選択します。

「セキュリティー」>「イントラネット」に進みます。
1. 「レベルのカスタマイズ」を選択します。「ユーザー認証」の「ログオン」で「イントラネットゾーンでのみ自動的にログオンする」オプションを選択します。
2. 「サイト」に進み、すべてのオプションを選択します。
3. 「詳細設定」をクリックして、Access Manager をローカルゾーンに追加します (まだ追加されていない場合)。

Windows NT

Access Manager は、すでにインストールされている Windows NT サーバーまたは Windows 2000 サーバーで使用できるように設定できます。Access Manager は、NT 認証のクライアント部分を担当します。

NT サーバーを設定します。詳しい手順については、Windows NT サーバーのマニュアルを参照してください。
Windows NT 認証モジュールを追加し、有効にする前に、Samba クライアントを入手してインストールし、Solaris システム上の Access Manager と通信できるようにする必要があります。

Samba クライアントのインストール

Windows NT 認証モジュールをアクティブにするには、Samba Client 2.2.2 をダウンロードして次のディレクトリにインストールする必要があります。

AccessManager-base/SUNWam/bin

Samba Client は、Windows マシンと UNIX マシンを共存させるためのファイルサーバー兼プリントサーバーで、専用の Windows NT/2000 Server を必要としません。詳細とダウンロードについては、http://wwws.sun.com/software/download/products/3e3af224.html を参照してください。

Red Hat Linux とともに出荷される Samba クライアントは、次のディレクトリに置かれています。

/usr/bin

Linux 用 Windows NT 認証モジュールを使って認証を行うためには、クライアントのバイナリを Access Manager の次のディレクトリにコピーします。

AccessManager-base/sun/identity/bin

注 –

複数のインタフェースがある場合には、追加の設定が必要です。複数のインタフェースは smb.conf ファイルで設定し、それを mbclient へ伝えることにより、設定できます。

認証モジュールインスタンス

デフォルトの認証モジュールに基づいて、複数の認証モジュールインスタンスをレルム用に作成できます。同じ認証モジュールを元に、個別に設定した複数のインスタンスを追加できます。

新しい認証モジュールインスタンスを作成する

手順

新しい認証モジュールインスタンスを追加するレルムの名前をクリックします。

「認証」タブを選択します。

注 –
「管理者認証設定」ボタンにより、管理者専用に認証サービスを定義できます。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。この属性で設定したモジュールは、Access Manager コンソールにアクセスするときに選択されます。

「モジュールインスタンス」リストの「新規」をクリックします。

認証モジュールインスタンスの名前を入力します。名前は一意にする必要があります。

レルムの認証モジュールタイプの「タイプ」を選択します。

「作成」をクリックします。

新しく作成したモジュールインスタンスの名前をクリックし、そのモジュールのプロパティーを編集します。各モジュールタイプのプロパティーの定義については、オンラインヘルプの「認証」の節を参照してください。

複数のモジュールインスタンスを追加するときは、これらの手順を繰り返します。

認証連鎖

1 つ以上の認証モジュールが設定できるので、ユーザーは認証資格をすべての認証モジュールに渡す必要があります。これは、認証連鎖と呼ばれます。Access Manager での認証連鎖は、認証サービスに統合された JAAS フレームワークを使用して実現されます。モジュール連鎖は、認証設定サービスの下に設定されます。

新しい認証連鎖を作成する

手順

新しい認証連鎖を追加するレルムの名前をクリックします。

「認証」タブを選択します。

「認証連鎖」リストの「新規」をクリックします。

認証連鎖の名前を入力します。

「作成」をクリックします。

「追加」をクリックし、連鎖に含める認証モジュールインスタンスを定義します。そのためには、「インスタンス」リストからモジュールインスタンス名を選択します。このリストに表示されるモジュールインスタンス名は、「モジュールインスタンス」属性で作成されます。

連鎖の条件を選択します。以上のフラグによって、認証モジュールの適用条件が確立されます。適用には階層があります。「必須」がもっとも高く、「オプション」がもっとも低くなります。

必要

認証にはモジュールインスタンスが必要です。認証に成功すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。認証に失敗すると、制御がただちにアプリケーションに返されます。この場合、「認証連鎖」リストの次のインスタンスには認証が進行しません。

必須

認証には、このモジュールへの認証が必要です。この連鎖の必須モジュールのいずれかが失敗すると、最終的に認証連鎖全体が失敗します。ただし、必須モジュールが成功しても失敗しても、連鎖の次のモジュールへと制御が進行します。

十分

認証にモジュールインスタンスは必要ありません。認証に成功するとすぐに、制御がアプリケーションに返されます。この場合、モジュールインスタンスリストの次のインスタンスには認証が進行しません。認証に失敗すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。

オプション

認証にモジュールインスタンスは必要ありません。認証に成功しても失敗しても、「認証連鎖」リストの次のインスタンスへと認証が進行します。

連鎖のオプションを入力します。これにより、モジュールの追加オプションがキーと値のペアとして有効になります。複数のオプションを指定するときは、スペースで区切ります。

次の属性を定義します。

「成功したログイン URL」

認証が成功した場合にユーザーをリダイレクトする URL を指定します。

「失敗したログイン URL」

認証が成功しなかった場合にユーザーをリダイレクトする URL を指定します。

「認証ポストプロセスクラス」

ログインが成功または失敗したあとに認証ポストプロセスのカスタマイズに使用する Java クラスの名前を定義します。

「保存」をクリックします。