20. 付録

20.1 セキュリティデータベーススキーマ

フレームワークで使用されるさまざまなデータベーススキーマがあり、この付録ではそれらすべてに対する単一の参照ポイントを提供します。必要な機能領域のテーブルのみを提供する必要があります。

HSQLDB データベース用の DDL ステートメントが提供されています。これらを、使用しているデータベースのスキーマを定義するためのガイドラインとして使用できます。

20.1.1 ユーザースキーマ

UserDetailsService (JdbcDaoImpl)の標準 JDBC 実装では、ユーザーのパスワード、アカウントステータス(有効または無効)、および権限のリスト(ロール)を読み込むためのテーブルが必要です。使用しているデータベースのダイアレクトに合わせて、このスキーマを調整する必要があります。

create table users(
    username varchar_ignorecase(50) not null primary key,
    password varchar_ignorecase(50) not null,
    enabled boolean not null
);

create table authorities (
    username varchar_ignorecase(50) not null,
    authority varchar_ignorecase(50) not null,
    constraint fk_authorities_users foreign key(username) references users(username)
);
create unique index ix_auth_username on authorities (username,authority);

Oracle データベースの場合

CREATE TABLE USERS (
    USERNAME NVARCHAR2(128) PRIMARY KEY,
    PASSWORD NVARCHAR2(128) NOT NULL,
    ENABLED CHAR(1) CHECK (ENABLED IN ('Y','N') ) NOT NULL
);


CREATE TABLE AUTHORITIES (
    USERNAME NVARCHAR2(128) NOT NULL,
    AUTHORITY NVARCHAR2(128) NOT NULL
);
ALTER TABLE AUTHORITIES ADD CONSTRAINT AUTHORITIES_UNIQUE UNIQUE (USERNAME, AUTHORITY);
ALTER TABLE AUTHORITIES ADD CONSTRAINT AUTHORITIES_FK1 FOREIGN KEY (USERNAME) REFERENCES USERS (USERNAME) ENABLE;

グループ権限

Spring Security 2.0 は、JdbcDaoImpl のグループ権限のサポートを導入しました。グループが有効な場合のテーブル構造は次のとおりです。使用しているデータベースのダイアレクトと一致するように、このスキーマを調整する必要があります。

create table groups (
    id bigint generated by default as identity(start with 0) primary key,
    group_name varchar_ignorecase(50) not null
);

create table group_authorities (
    group_id bigint not null,
    authority varchar(50) not null,
    constraint fk_group_authorities_group foreign key(group_id) references groups(id)
);

create table group_members (
    id bigint generated by default as identity(start with 0) primary key,
    username varchar(50) not null,
    group_id bigint not null,
    constraint fk_group_members_group foreign key(group_id) references groups(id)
);

これらのテーブルは、提供されている JDBC UserDetailsService 実装を使用している場合にのみ必要であることに注意してください。独自に作成するか、UserDetailsService を使用せずに AuthenticationProvider を実装することを選択した場合、インターフェース契約が満たされていれば、データの保存方法を完全に自由に選択できます。

20.1.2 永続的ログイン(Remember-Me)スキーマ

このテーブルは、より安全な永久トークン remember-me 実装で使用されるデータを保存するために使用されます。JdbcTokenRepositoryImpl を直接またはネームスペースを介して使用している場合、このテーブルが必要になります。このスキーマを調整して、使用しているデータベースのダイアレクトに合わせてください。

create table persistent_logins (
    username varchar(64) not null,
    series varchar(64) primary key,
    token varchar(64) not null,
    last_used timestamp not null
);

20.1.3 ACL スキーマ

Spring Security ACL 実装で使用される 4 つのテーブルがあります。

  1. acl_sid は、ACL システムによって認識されたセキュリティ ID を保存します。これらは、複数のプリンシパルに適用される可能性がある一意のプリンシパルまたは機関である場合があります。
  2. acl_class は、ACL が適用されるドメインオブジェクト型を定義します。class 列には、オブジェクトの Java クラス名が格納されます。
  3. acl_object_identity は、特定のドメインオブジェクトのオブジェクト ID 定義を保存します。
  4. acl_entry は、特定のオブジェクト ID とセキュリティ ID に適用される ACL 許可を保存します。

データベースは、各アイデンティティのプライマリキーを自動生成すると想定されています。JdbcMutableAclService は、acl_sid または acl_class テーブルに新しい行を作成したときにこれらを取得できる必要があります。これらの値 classIdentityQuery および sidIdentityQuery を取得するために必要な SQL を定義する 2 つのプロパティがあります。これらは両方とも call identity() のデフォルトです

ACL アーティファクト JAR には、HyperSQL(HSQLDB)、PostgreSQL、MySQL/MariaDB、Microsoft SQL Server、および Oracle データベースで ACL スキーマを作成するためのファイルが含まれています。これらのスキーマについては、次のセクションでも説明します。

HyperSQL

デフォルトのスキーマは、フレームワーク内の単体テストで使用される埋め込み HSQLDB データベースで機能します。

create table acl_sid(
    id bigint generated by default as identity(start with 100) not null primary key,
    principal boolean not null,
    sid varchar_ignorecase(100) not null,
    constraint unique_uk_1 unique(sid,principal)
);

create table acl_class(
    id bigint generated by default as identity(start with 100) not null primary key,
    class varchar_ignorecase(100) not null,
    constraint unique_uk_2 unique(class)
);

create table acl_object_identity(
    id bigint generated by default as identity(start with 100) not null primary key,
    object_id_class bigint not null,
    object_id_identity varchar_ignorecase(36) not null,
    parent_object bigint,
    owner_sid bigint,
    entries_inheriting boolean not null,
    constraint unique_uk_3 unique(object_id_class,object_id_identity),
    constraint foreign_fk_1 foreign key(parent_object)references acl_object_identity(id),
    constraint foreign_fk_2 foreign key(object_id_class)references acl_class(id),
    constraint foreign_fk_3 foreign key(owner_sid)references acl_sid(id)
);

create table acl_entry(
    id bigint generated by default as identity(start with 100) not null primary key,
    acl_object_identity bigint not null,
    ace_order int not null,
    sid bigint not null,
    mask integer not null,
    granting boolean not null,
    audit_success boolean not null,
    audit_failure boolean not null,
    constraint unique_uk_4 unique(acl_object_identity,ace_order),
    constraint foreign_fk_4 foreign key(acl_object_identity) references acl_object_identity(id),
    constraint foreign_fk_5 foreign key(sid) references acl_sid(id)
);

PostgreSQL

create table acl_sid(
    id bigserial not null primary key,
    principal boolean not null,
    sid varchar(100) not null,
    constraint unique_uk_1 unique(sid,principal)
);

create table acl_class(
    id bigserial not null primary key,
    class varchar(100) not null,
    constraint unique_uk_2 unique(class)
);

create table acl_object_identity(
    id bigserial primary key,
    object_id_class bigint not null,
    object_id_identity varchar(36) not null,
    parent_object bigint,
    owner_sid bigint,
    entries_inheriting boolean not null,
    constraint unique_uk_3 unique(object_id_class,object_id_identity),
    constraint foreign_fk_1 foreign key(parent_object)references acl_object_identity(id),
    constraint foreign_fk_2 foreign key(object_id_class)references acl_class(id),
    constraint foreign_fk_3 foreign key(owner_sid)references acl_sid(id)
);

create table acl_entry(
    id bigserial primary key,
    acl_object_identity bigint not null,
    ace_order int not null,
    sid bigint not null,
    mask integer not null,
    granting boolean not null,
    audit_success boolean not null,
    audit_failure boolean not null,
    constraint unique_uk_4 unique(acl_object_identity,ace_order),
    constraint foreign_fk_4 foreign key(acl_object_identity) references acl_object_identity(id),
    constraint foreign_fk_5 foreign key(sid) references acl_sid(id)
);

JdbcMutableAclService の classIdentityQuery プロパティと sidIdentityQuery プロパティをそれぞれ次の値に設定する必要があります。

  • select currval(pg_get_serial_sequence('acl_class', 'id'))
  • select currval(pg_get_serial_sequence('acl_sid', 'id'))

MySQL および MariaDB

CREATE TABLE acl_sid (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    principal BOOLEAN NOT NULL,
    sid VARCHAR(100) NOT NULL,
    UNIQUE KEY unique_acl_sid (sid, principal)
) ENGINE=InnoDB;

CREATE TABLE acl_class (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    class VARCHAR(100) NOT NULL,
    UNIQUE KEY uk_acl_class (class)
) ENGINE=InnoDB;

CREATE TABLE acl_object_identity (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    object_id_class BIGINT UNSIGNED NOT NULL,
    object_id_identity VARCHAR(36) NOT NULL,
    parent_object BIGINT UNSIGNED,
    owner_sid BIGINT UNSIGNED,
    entries_inheriting BOOLEAN NOT NULL,
    UNIQUE KEY uk_acl_object_identity (object_id_class, object_id_identity),
    CONSTRAINT fk_acl_object_identity_parent FOREIGN KEY (parent_object) REFERENCES acl_object_identity (id),
    CONSTRAINT fk_acl_object_identity_class FOREIGN KEY (object_id_class) REFERENCES acl_class (id),
    CONSTRAINT fk_acl_object_identity_owner FOREIGN KEY (owner_sid) REFERENCES acl_sid (id)
) ENGINE=InnoDB;

CREATE TABLE acl_entry (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    acl_object_identity BIGINT UNSIGNED NOT NULL,
    ace_order INTEGER NOT NULL,
    sid BIGINT UNSIGNED NOT NULL,
    mask INTEGER UNSIGNED NOT NULL,
    granting BOOLEAN NOT NULL,
    audit_success BOOLEAN NOT NULL,
    audit_failure BOOLEAN NOT NULL,
    UNIQUE KEY unique_acl_entry (acl_object_identity, ace_order),
    CONSTRAINT fk_acl_entry_object FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity (id),
    CONSTRAINT fk_acl_entry_acl FOREIGN KEY (sid) REFERENCES acl_sid (id)
) ENGINE=InnoDB;

Microsoft SQL Server

CREATE TABLE acl_sid (
    id BIGINT NOT NULL IDENTITY PRIMARY KEY,
    principal BIT NOT NULL,
    sid VARCHAR(100) NOT NULL,
    CONSTRAINT unique_acl_sid UNIQUE (sid, principal)
);

CREATE TABLE acl_class (
    id BIGINT NOT NULL IDENTITY PRIMARY KEY,
    class VARCHAR(100) NOT NULL,
    CONSTRAINT uk_acl_class UNIQUE (class)
);

CREATE TABLE acl_object_identity (
    id BIGINT NOT NULL IDENTITY PRIMARY KEY,
    object_id_class BIGINT NOT NULL,
    object_id_identity VARCHAR(36) NOT NULL,
    parent_object BIGINT,
    owner_sid BIGINT,
    entries_inheriting BIT NOT NULL,
    CONSTRAINT uk_acl_object_identity UNIQUE (object_id_class, object_id_identity),
    CONSTRAINT fk_acl_object_identity_parent FOREIGN KEY (parent_object) REFERENCES acl_object_identity (id),
    CONSTRAINT fk_acl_object_identity_class FOREIGN KEY (object_id_class) REFERENCES acl_class (id),
    CONSTRAINT fk_acl_object_identity_owner FOREIGN KEY (owner_sid) REFERENCES acl_sid (id)
);

CREATE TABLE acl_entry (
    id BIGINT NOT NULL IDENTITY PRIMARY KEY,
    acl_object_identity BIGINT NOT NULL,
    ace_order INTEGER NOT NULL,
    sid BIGINT NOT NULL,
    mask INTEGER NOT NULL,
    granting BIT NOT NULL,
    audit_success BIT NOT NULL,
    audit_failure BIT NOT NULL,
    CONSTRAINT unique_acl_entry UNIQUE (acl_object_identity, ace_order),
    CONSTRAINT fk_acl_entry_object FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity (id),
    CONSTRAINT fk_acl_entry_acl FOREIGN KEY (sid) REFERENCES acl_sid (id)
);

Oracle データベース

CREATE TABLE ACL_SID (
    ID NUMBER(18) PRIMARY KEY,
    PRINCIPAL NUMBER(1) NOT NULL CHECK (PRINCIPAL IN (0, 1 )),
    SID NVARCHAR2(128) NOT NULL,
    CONSTRAINT ACL_SID_UNIQUE UNIQUE (SID, PRINCIPAL)
);
CREATE SEQUENCE ACL_SID_SQ START WITH 1 INCREMENT BY 1 NOMAXVALUE;
CREATE OR REPLACE TRIGGER ACL_SID_SQ_TR BEFORE INSERT ON ACL_SID FOR EACH ROW
BEGIN
    SELECT ACL_SID_SQ.NEXTVAL INTO :NEW.ID FROM DUAL;
END;


CREATE TABLE ACL_CLASS (
    ID NUMBER(18) PRIMARY KEY,
    CLASS NVARCHAR2(128) NOT NULL,
    CONSTRAINT ACL_CLASS_UNIQUE UNIQUE (CLASS)
);
CREATE SEQUENCE ACL_CLASS_SQ START WITH 1 INCREMENT BY 1 NOMAXVALUE;
CREATE OR REPLACE TRIGGER ACL_CLASS_ID_TR BEFORE INSERT ON ACL_CLASS FOR EACH ROW
BEGIN
    SELECT ACL_CLASS_SQ.NEXTVAL INTO :NEW.ID FROM DUAL;
END;


CREATE TABLE ACL_OBJECT_IDENTITY(
    ID NUMBER(18) PRIMARY KEY,
    OBJECT_ID_CLASS NUMBER(18) NOT NULL,
    OBJECT_ID_IDENTITY NVARCHAR2(64) NOT NULL,
    PARENT_OBJECT NUMBER(18),
    OWNER_SID NUMBER(18),
    ENTRIES_INHERITING NUMBER(1) NOT NULL CHECK (ENTRIES_INHERITING IN (0, 1)),
    CONSTRAINT ACL_OBJECT_IDENTITY_UNIQUE UNIQUE (OBJECT_ID_CLASS, OBJECT_ID_IDENTITY),
    CONSTRAINT ACL_OBJECT_IDENTITY_PARENT_FK FOREIGN KEY (PARENT_OBJECT) REFERENCES ACL_OBJECT_IDENTITY(ID),
    CONSTRAINT ACL_OBJECT_IDENTITY_CLASS_FK FOREIGN KEY (OBJECT_ID_CLASS) REFERENCES ACL_CLASS(ID),
    CONSTRAINT ACL_OBJECT_IDENTITY_OWNER_FK FOREIGN KEY (OWNER_SID) REFERENCES ACL_SID(ID)
);
CREATE SEQUENCE ACL_OBJECT_IDENTITY_SQ START WITH 1 INCREMENT BY 1 NOMAXVALUE;
CREATE OR REPLACE TRIGGER ACL_OBJECT_IDENTITY_ID_TR BEFORE INSERT ON ACL_OBJECT_IDENTITY FOR EACH ROW
BEGIN
    SELECT ACL_OBJECT_IDENTITY_SQ.NEXTVAL INTO :NEW.ID FROM DUAL;
END;


CREATE TABLE ACL_ENTRY (
    ID NUMBER(18) NOT NULL PRIMARY KEY,
    ACL_OBJECT_IDENTITY NUMBER(18) NOT NULL,
    ACE_ORDER INTEGER NOT NULL,
    SID NUMBER(18) NOT NULL,
    MASK INTEGER NOT NULL,
    GRANTING NUMBER(1) NOT NULL CHECK (GRANTING IN (0, 1)),
    AUDIT_SUCCESS NUMBER(1) NOT NULL CHECK (AUDIT_SUCCESS IN (0, 1)),
    AUDIT_FAILURE NUMBER(1) NOT NULL CHECK (AUDIT_FAILURE IN (0, 1)),
    CONSTRAINT ACL_ENTRY_UNIQUE UNIQUE (ACL_OBJECT_IDENTITY, ACE_ORDER),
    CONSTRAINT ACL_ENTRY_OBJECT_FK FOREIGN KEY (ACL_OBJECT_IDENTITY) REFERENCES ACL_OBJECT_IDENTITY (ID),
    CONSTRAINT ACL_ENTRY_ACL_FK FOREIGN KEY (SID) REFERENCES ACL_SID(ID)
);
CREATE SEQUENCE ACL_ENTRY_SQ START WITH 1 INCREMENT BY 1 NOMAXVALUE;
CREATE OR REPLACE TRIGGER ACL_ENTRY_ID_TRIGGER BEFORE INSERT ON ACL_ENTRY FOR EACH ROW
BEGIN
    SELECT ACL_ENTRY_SQ.NEXTVAL INTO :NEW.ID FROM DUAL;
END;

20.2 セキュリティ名前空間

この付録では、セキュリティネームスペースで使用可能な要素への参照と、作成する基礎となる Bean に関する情報を提供します(個々のクラスおよびそれらの連携メソッドに関する知識が想定されます。詳細については、プロジェクト Javadoc およびこのドキュメントの他の場所を参照してください))。ネームスペースを使用したことがない場合は、ネームスペースの構成に関する入門章を参照してください。これは、そこにある情報の補足として意図されています。スキーマに基づいて構成を編集する際に良質の XML エディターを使用することをお勧めします。これにより、使用可能な要素と属性に関するコンテキスト情報と、その目的を説明するコメントが提供されます。名前空間は RELAX NG (英語) Compact 形式で記述され、後で XSD スキーマに変換されます。この形式に精通している場合は、スキーマファイル (英語) を直接調べてください。

20.2.1 Web アプリケーションセキュリティ

<debug>

Spring Security デバッグインフラストラクチャを有効にします。これにより、人間が読める(複数行の)デバッグ情報が提供され、セキュリティフィルターに送られるリクエストを監視できます。これには、リクエストパラメーターやヘッダーなどの機密情報が含まれる場合があり、開発環境でのみ使用する必要があります。

<http>

アプリケーション内で <http> 要素を使用する場合、「springSecurityFilterChain」という名前の FilterChainProxy Bean が作成され、要素内の構成を使用して FilterChainProxy 内のフィルターチェーンが構築されます。Spring Security 3.1 以降、追加の http 要素を使用して、追加のフィルターチェーン [14] を追加できます。一部のコアフィルターは常にフィルターチェーンで作成され、その他は存在する属性と子要素に応じてスタックに追加されます。標準フィルターの位置は固定され(名前空間の概要のフィルター順序表を参照)、ユーザーが FilterChainProxy Bean でフィルターチェーンを明示的に構成する必要があったときに、フレームワークの以前のバージョンでのエラーの一般的な原因を取り除きます。もちろん、構成を完全に制御する必要がある場合は、これを行うことができます。

AuthenticationManager への参照を必要とするすべてのフィルターには、名前空間構成によって作成された内部インスタンスが自動的に挿入されます(AuthenticationManager の詳細については、導入の章を参照してください)。

各 <http> 名前空間ブロックは、常に SecurityContextPersistenceFilterExceptionTranslationFilter および FilterSecurityInterceptor を作成します。これらは修正されており、代替に置き換えることはできません。

<http> の属性

<http> 要素の属性は、コアフィルターの一部のプロパティを制御します。

  • access-decision-manager-ref HTTP リクエストの承認に使用する AccessDecisionManager 実装の ID を指定するオプションの属性。デフォルトでは、AffirmativeBased 実装は RoleVoter および AuthenticatedVoter で使用されます。
  • authentication-manager-ref この http 要素によって作成された FilterChain に使用される AuthenticationManager への参照。
  • auto-config ログインフォーム、BASIC 認証、ログアウトサービスを自動的に登録します。「true」に設定すると、これらの機能がすべて追加されます(ただし、それぞれの要素を指定することで、それぞれの構成をカスタマイズできます)。指定しない場合、デフォルトは「false」です。この属性の使用は推奨されません。混乱を避けるために、代わりに明示的な構成要素を使用してください。
  • create-session Spring Security クラスによって HTTP セッションが作成される際の熱心さを制御します。オプションが含まれます:

    • always - Spring Security は、セッションが存在しない場合、積極的にセッションを作成します。
    • ifRequired - Spring Security は、セッションが必要な場合にのみセッションを作成します(デフォルト値)。
    • never - Spring Security はセッションを作成しませんが、アプリケーションが作成した場合はセッションを使用します。
    • stateless - Spring Security はセッションを作成せず、Spring Authentication を取得するためのセッションを無視します。
  • disable-url-rewriting セッション ID がアプリケーションの URL に追加されないようにします。この属性が true に設定されている場合、クライアントは Cookie を使用する必要があります。デフォルトは true です。
  • entry-point-ref 通常、使用される AuthenticationEntryPoint は、設定されている認証メカニズムに応じて設定されます。この属性により、認証プロセスを開始するカスタマイズされた AuthenticationEntryPoint Bean を定義することにより、この動作をオーバーライドできます。
  • jaas-api-provision 可能であれば、JaasApiIntegrationFilter Bean をスタックに追加することによって実装される JaasAuthenticationToken から取得した Subject としてリクエストを実行します。デフォルトは false です。
  • name Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • once-per-requestFilterSecurityInterceptor の observeOncePerRequest プロパティに対応します。デフォルトは true です。
  • pattern http 要素のパターンを定義すると、定義されているフィルターのリストを介してフィルターされるリクエストが制御されます。解釈は、構成された request-matcher に依存します。パターンが定義されていない場合、すべてのリクエストが一致するため、最も具体的なパターンを最初に宣言する必要があります。
  • realm 基本認証に使用されるレルム名を設定します(有効な場合)。BasicAuthenticationEntryPoint の realmName プロパティに対応します。
  • request-matcherFilterChainProxy で使用される RequestMatcher 戦略と、受信リクエストに一致するように intercept-url によって作成される Bean を定義します。オプションは現在 mvcantregexciRegex で、Spring MVC、ant、正規表現、大文字と小文字を区別しない正規表現がそれぞれあります。patternmethodservlet-path 属性を使用して、intercept-url 要素ごとに個別のインスタンスが作成されます。Ant パスは AntPathRequestMatcher を使用して照合され、正規表現は RegexRequestMatcher を使用して照合され、Spring MVC パスの照合には MvcRequestMatcher が使用されます。マッチングの正確な実行方法の詳細については、これらのクラスの Javadoc を参照してください。Ant パスがデフォルトの戦略です。
  • request-matcher-refRequestMatcher を実装する Bean への参照。この FilterChain を使用するかどうかを決定します。これは pattern のより強力な代替手段です。
  • security この属性を none に設定することにより、リクエストパターンを空のフィルターチェーンにマップできます。セキュリティは適用されず、Spring Security の機能は使用できません。
  • security-context-repository-ref カスタム SecurityContextRepository を SecurityContextPersistenceFilter に注入できます。
  • servlet-api-provisionSecurityContextHolderAwareRequestFilter Bean をスタックに追加することにより実装される、isUserInRole() や getPrincipal() などの HttpServletRequest セキュリティメソッドのバージョンを提供します。デフォルトは true です。

<access-denied-handler>

この要素を使用すると、error-page 属性を使用して ExceptionTranslationFilter が使用するデフォルト AccessDeniedHandler の errorPage プロパティを設定したり、ref 属性を使用して独自の実装を提供したりできます。これについては、ExceptionTranslationFilter のセクションで詳しく説明します。

<access-denied-handler> の親要素
<access-denied-handler> の属性
  • error-page 認証されたユーザーがアクセス権限のないページをリクエストした場合にリダイレクトされるアクセス拒否ページ。
  • ref 型 AccessDeniedHandler の Spring Bean への参照を定義します。

<cors>

この要素を使用すると、CorsFilter を構成できます。CorsFilter または CorsConfigurationSource が指定されておらず、Spring MVC がクラスパス上にある場合、HandlerMappingIntrospector が CorsConfigurationSource として使用されます。

<cors> 属性

<cors> 要素の属性は、headers 要素を制御します。

  • refCorsFilter の Bean 名を指定するオプションの属性。
  • cors-configuration-source-ref XML 名前空間によって作成された CorsFilter に挿入される CorsConfigurationSource の Bean 名を指定するオプションの属性。
<cors> の親要素

<headers>

この要素を使用すると、追加の(セキュリティ)ヘッダーをレスポンスとともに送信するように構成できます。これにより、複数のヘッダーを簡単に構成でき、ヘッダー要素を介してカスタムヘッダーを設定することもできます。追加情報は、リファレンスのセキュリティヘッダーセクションにあります。

  • Cache-ControlPragmaExpires - cache-control 要素を使用して設定できます。これにより、ブラウザーが保護されたページをキャッシュしないようになります。
  • Strict-Transport-Security - hsts 要素を使用して設定できます。これにより、将来のリクエストに対してブラウザーが HTTPS を自動的にリクエストするようになります。
  • X-Frame-Options - frame-options 要素を使用して設定できます。X-Frame-Options (英語) ヘッダーは、クリックジャック攻撃を防ぐために使用できます。
  • X-XSS-Protection - xss-protection 要素を使用して設定できます。X-XSS-Protection (英語) ヘッダーは、基本的な制御を行うためにブラウザーで使用できます。
  • X-Content-Type-Options - content-type-options 要素を使用して設定できます。X-Content-Type-Options (英語) ヘッダーは、Internet Explorer が宣言されたコンテンツタイプからレスポンスを MIME スニッフィングすることを防ぎます。これは、拡張機能をダウンロードする際の Google Chrome にも適用されます。
  • Public-Key-Pinning または Public-Key-Pinning-Report-Only - hpkp 要素を使用して設定できます。これにより、HTTPS Web サイトは、誤って発行された証明書または不正な証明書を使用した攻撃者によるなりすましに抵抗することができます。
  • Content-Security-Policy または Content-Security-Policy-Report-Only - content-security-policy エレメントを使用して設定できます。コンテンツセキュリティポリシー (CSP) (英語) は、クロスサイトスクリプティング(XSS)などのコンテンツインジェクションの脆弱性を軽減するために Web アプリケーションが活用できるメカニズムです。
  • Referrer-Policy - referrer -policy 要素を使用して設定できます。リファラーポリシー (英語) は、Web アプリケーションがリファラーフィールドを管理するために利用できるメカニズムです。リファラーフィールドには、ユーザーが最後にアクセスしたページが含まれます。
  • Feature-Policy - feature-policy エレメントを使用して設定できます。機能ポリシー (英語) は、Web 開発者がブラウザーの特定の API および Web 機能の動作を選択的に有効化、無効化、変更できるメカニズムです。
<headers> 属性

<headers> 要素の属性は、headers 要素を制御します。

  • defaults-disabled デフォルトの Spring Security の HTTP レスポンスヘッダーを無効にすることを指定するオプションの属性。デフォルトは false です(デフォルトのヘッダーが含まれます)。
  • disabled Spring Security の HTTP レスポンスヘッダーを無効にすることを指定するオプションの属性。デフォルトは false です(ヘッダーは有効です)。
<headers> の親要素

<cache-control>

Cache-ControlPragmaExpires ヘッダーを追加して、ブラウザーが保護されたページをキャッシュしないようにします。

<cache-control> の属性
  • disabled キャッシュ制御を無効にするかどうかを指定します。デフォルトは false。
<cache-control> の親要素

<hsts>

有効にすると、Strict-Transport-Security (英語) ヘッダーが安全なリクエストのレスポンスに追加されます。これにより、サーバーは、将来のリクエストで HTTPS を自動的に使用するようブラウザーに指示できます。

<hsts> の属性
  • disabled Strict-Transport-Security を無効にするかどうかを指定します。デフォルトは false。
  • include-sub-domains サブドメインを含めるかどうかを指定します。デフォルトは true。
  • max-age-seconds ホストが既知の HSTS ホストと見なされる最大時間を指定します。デフォルトは 1 年。
  • request-matcher-ref ヘッダーを設定する必要があるかどうかを判断するために使用される RequestMatcher インスタンス。デフォルトは、HttpServletRequest.isSecure() が true の場合です。
  • preload プリロードを含めるかどうかを指定します。デフォルトは false。
<hsts> の親要素

<hpkp>

有効にすると、HTTP の公開キー固定拡張 (英語) ヘッダーが安全なリクエストのレスポンスに追加されます。これにより、HTTPS Web サイトは、誤って発行された証明書または不正な証明書を使用した攻撃者によるなりすましに抵抗できます。

<hpkp> の属性
  • disabled HTTP 公開キー固定(HPKP)を無効にするかどうかを指定します。デフォルトは true。
  • include-sub-domains サブドメインを含めるかどうかを指定します。デフォルトは false。
  • max-age-seconds Public-Key-Pins ヘッダーの max-age ディレクティブの値を設定します。デフォルトは 60 日です。
  • report-only ブラウザーがピン検証の失敗のみを報告するかどうかを指定します。デフォルトは true。
  • report-uri ブラウザーがピン検証の失敗を報告する URI を指定します。
<hpkp> の親要素

<pins>

ピンのリスト

<pins> の子要素

<pin>

ピンは、値として base64 エンコード SPKI フィンガープリントを使用し、属性として暗号化ハッシュアルゴリズムを使用して指定されます

<pin> 属性
  • algorithm 暗号化ハッシュアルゴリズム。デフォルトは SHA256 です。
<pin> の親要素

<content-security-policy>

有効にすると、コンテンツセキュリティポリシー (CSP) (英語) ヘッダーがレスポンスに追加されます。CSP は、クロスサイトスクリプティング(XSS)など、Web アプリケーションがコンテンツインジェクションの脆弱性を軽減するために活用できるメカニズムです。

<content-security-policy> の属性
  • policy-directives Content-Security-Policy ヘッダーのセキュリティポリシーディレクティブ、または report-only が true に設定されている場合、Content-Security-Policy-Report-Only ヘッダーが使用されます。
  • report-only true に設定すると、ポリシー違反のみを報告するために Content-Security-Policy-Report-Only ヘッダーが有効になります。デフォルトは false です。
<content-security-policy> の親要素

<referrer-policy>

有効にすると、リファラーポリシー (英語) ヘッダーがレスポンスに追加されます。

<referrer-policy> の属性
  • policy Referrer-Policy ヘッダーのポリシー。デフォルトの「リファラーなし」。
<referrer-policy> の親要素

<feature-policy>

有効にすると、機能ポリシー (英語) ヘッダーがレスポンスに追加されます。

<feature-policy> の属性
  • policy-directives Feature-Policy ヘッダーのセキュリティポリシーディレクティブ。
<feature-policy> の親要素

<frame-options>

有効にすると、X-Frame-Options ヘッダー (英語) がレスポンスに追加されます。これにより、新しいブラウザーはセキュリティチェックを行い、クリックジャック (英語) 攻撃を防ぐことができます。

<frame-options> 属性
  • disabled 無効にすると、X-Frame-Options ヘッダーは含まれません。デフォルトは false。
  • 政策

    • DENY サイトは、フレームを表示しようとしているかどうかにかかわらず、フレームに表示できません。これは、frame-options-policy が指定されている場合のデフォルトです。
    • SAMEORIGIN ページは、ページ自体と同じ原点のフレームにのみ表示できます
    • ALLOW-FROM origin ページは、指定された原点のフレームにのみ表示できます。

    つまり、DENY を指定すると、他のサイトからロードされたときにフレーム内のページのロードが失敗するだけでなく、同じサイトからロードされたときにも失敗します。一方、SAMEORIGIN を指定した場合、フレームにページを含むサイトがページを提供しているサイトと同じである限り、フレームでページを使用できます。

  • strategy ALLOW-FROM ポリシーを使用するときに使用する AllowFromStrategy を選択します。

    • static 単一の静的 ALLOW-FROM 値を使用します。値は、value 属性を介して設定できます。
    • regexp regelur 式を使用して、受信リクエストとそれらが許可されているかどうかを検証します。正規表現は、value 属性を介して設定できます。検証する値を取得するために使用されるリクエストパラメーターは、from-parameter を使用して指定できます。
    • whitelist 許可されたドメインを含むコンマ区切りリスト。コンマ区切りのリストは、value 属性を介して設定できます。検証する値を取得するために使用されるリクエストパラメーターは、from-parameter を使用して指定できます。
  • ref 定義済みの戦略の 1 つを使用する代わりに、カスタム AllowFromStrategy を使用することもできます。この Bean への参照は、この ref 属性を介して指定できます。
  • value ALLOW-FROM が戦略として使用される場合に使用する値。
  • from-parameter ALLOW-FROM 戦略に regexp またはホワイトリストを使用するときに使用するリクエストパラメーターの名前を指定します。
<frame-options> の親要素

<xss-protection>

X-XSS-Protection ヘッダー (英語) をレスポンスに追加して、反映 / タイプ 1 クロスサイトスクリプティング (XSS) (英語) 攻撃からの保護を支援します。これは決して XSS 攻撃に対する完全な保護ではありません!

<xss-protection> 属性
  • xss-protection-block true で xss-protection-enabled が true の場合、mode = block をヘッダーに追加します。これは、ページをまったくロードしないことをブラウザーに示します。false で xss-protection-enabled が true の場合、リフレクション攻撃が検出されるとページは引き続きレンダリングされますが、攻撃から保護するためにレスポンスが変更されます。このモードをバイパスする方法が時々あることに注意してください。多くの場合、ページのブロックをより望ましいものにすることができます。
<xss-protection> の親要素

<content-type-options>

nosniff の値を持つ X-Content-Type-Options ヘッダーをレスポンスに追加します。これにより、IE8 + および Chrome 拡張の MIME スニッフィングが無効になります (英語)

<content-type-options> 属性
  • disabled コンテンツタイプオプションを無効にするかどうかを指定します。デフォルトは false。
<content-type-options> の親要素

<header>

レスポンスにヘッダーを追加します。名前と値の両方を指定する必要があります。

<header-attributes> 属性
  • header-name ヘッダーの name
  • value 追加するヘッダーの value
  • refHeaderWriter インターフェースのカスタム実装への参照。
<header> の親要素

<anonymous>

AnonymousAuthenticationFilter をスタックに追加し、AnonymousAuthenticationProvider を追加します。IS_AUTHENTICATED_ANONYMOUSLY 属性を使用している場合は必須。

<anonymous> の親要素
<anonymous> 属性
  • enabled デフォルトのネームスペースのセットアップでは、匿名の「認証」機能が自動的に有効になります。このプロパティを使用して無効にできます。
  • granted-authority 匿名リクエストに割り当てる必要のある権限。通常、これは匿名リクエストに特定のロールを割り当てるために使用され、その後、認可の決定に使用できます。設定しない場合、デフォルトは ROLE_ANONYMOUS になります。
  • key プロバイダーとフィルター間で共有されるキー。通常、これを設定する必要はありません。設定されていない場合、デフォルトで安全にランダムに生成された値になります。つまり、この値を設定すると、匿名機能を使用する際に、セキュアなランダム値が生成されるまでに時間がかかるため、起動時間が改善されます。
  • username 匿名リクエストに割り当てられるユーザー名。これにより、プリンシパルを識別できるようになります。これは、ロギングと監査に重要な場合があります。設定しない場合、デフォルトは anonymousUser になります。

<csrf>

この要素は、クロスサイトリクエストフォージャー (CSRF) (英語) 保護をアプリケーションに追加します。また、デフォルトの RequestCache を更新して、認証が成功したときにのみ「GET」リクエストを再生します。追加情報は、リファレンスのクロスサイトリクエストフォージェリ (CSRF) セクションにあります。

<csrf> の親要素
<csrf> の属性
  • disabled Spring Security の CSRF 保護を無効にすることを指定するオプションの属性。デフォルトは false です(CSRF 保護は有効です)。CSRF 保護を有効のままにしておくことを強くお勧めします。
  • token-repository-ref 使用する CsrfTokenRepository。デフォルトは HttpSessionCsrfTokenRepository です。
  • request-matcher-ref CSRF を適用するかどうかを決定するために使用される RequestMatcher インスタンス。デフォルトは、「GET」、「TRACE」、「HEAD」、「OPTIONS」を除く任意の HTTP メソッドです。

<custom-filter>

この要素は、フィルターチェーンにフィルターを追加するために使用されます。追加の Bean は作成されませんが、アプリケーションコンテキストですでに定義されている型 javax.servlet.Filter の Bean を選択し、Spring Security によって維持されるフィルターチェーンの特定の位置に追加するために使用されます。詳細については、名前空間の章を参照してください。

<custom-filter> の親要素
<custom-filter> 属性
  • after チェーンにカスタムフィルターを配置する直後のフィルター。この機能は、独自のフィルターをセキュリティフィルターチェーンにミックスし、標準の Spring Security フィルターの知識がある上級ユーザーのみが必要とします。フィルター名は、特定の Spring Security 実装フィルターにマップされます。
  • before チェーンにカスタムフィルターを配置する直前のフィルター
  • position チェーンでカスタムフィルターを配置する明示的な位置。標準フィルターを交換する場合に使用します。
  • refFilter を実装する Spring Bean への参照を定義します。

<expression-handler>

式ベースのアクセス制御が有効な場合に使用される SecurityExpressionHandler インスタンスを定義します。指定されていない場合、デフォルトの実装(ACL サポートなし)が使用されます。

<expression-handler> の親要素
<expression-handler> の属性
  • refSecurityExpressionHandler を実装する Spring Bean への参照を定義します。

<form-login>

オンデマンドで認証を提供するために、UsernamePasswordAuthenticationFilter をフィルタースタックに追加し、LoginUrlAuthenticationEntryPoint をアプリケーションコンテキストに追加するために使用します。これは、名前空間で作成された他のエントリポイントよりも常に優先されます。属性が指定されていない場合、URL "/login" [15] でログインページが自動的に生成されます。動作は <form-login> 属性を使用してカスタマイズできます。

<form-login> の親要素
<form-login> 属性
  • always-use-default-targettrue に設定した場合、ユーザーはログインページに到達した方法に関係なく、常に default-target-url で指定された値から開始します。UsernamePasswordAuthenticationFilter の alwaysUseDefaultTargetUrl プロパティにマップします。デフォルト値は false です。
  • authentication-details-source-ref 認証フィルターによって使用される AuthenticationDetailsSource への参照
  • authentication-failure-handler-ref authentication-failure-url の代替として使用でき、認証失敗後のナビゲーションフローを完全に制御できます。値は、アプリケーションコンテキストの AuthenticationFailureHandler Bean の名前である必要があります。
  • authentication-failure-urlUsernamePasswordAuthenticationFilter の authenticationFailureUrl プロパティにマップします。ログイン失敗時にブラウザーがリダイレクトされる URL を定義します。デフォルトは /login?error であり、これは自動ログインページジェネレーターによって自動的に処理され、エラーメッセージでログインページを再レンダリングします。
  • authentication-success-handler-ref これは、default-target-url および always-use-default-target の代替として使用でき、認証が成功した後のナビゲーションフローを完全に制御できます。値は、アプリケーションコンテキストの AuthenticationSuccessHandler Bean の名前である必要があります。デフォルトでは、SavedRequestAwareAuthenticationSuccessHandler の実装が使用され、default-target-url が挿入されます。
  • default-target-urlUsernamePasswordAuthenticationFilter の defaultTargetUrl プロパティにマップします。設定されていない場合、デフォルト値は「/」(アプリケーションルート)です。ユーザーは、ログイン後にこの URL に移動します。ただし、保護されたリソースにアクセスしようとしてログインを求められなかった場合、最初にリクエストされた URL に移動します。
  • login-page ログインページのレンダリングに使用する URL。LoginUrlAuthenticationEntryPoint の loginFormUrl プロパティにマップします。デフォルトは「/login」です。
  • login-processing-urlUsernamePasswordAuthenticationFilter の filterProcessesUrl プロパティにマップします。デフォルト値は「/login」です。
  • password-parameter パスワードを含むリクエストパラメーターの名前。デフォルトは「password」です。
  • username-parameter ユーザー名を含むリクエストパラメーターの名前。デフォルトは「username」です。
  • authentication-success-forward-urlForwardAuthenticationSuccessHandler を UsernamePasswordAuthenticationFilter の authenticationSuccessHandler プロパティにマップします。
  • authentication-failure-forward-urlForwardAuthenticationFailureHandler を UsernamePasswordAuthenticationFilter の authenticationFailureHandler プロパティにマップします。

<http-basic>

BasicAuthenticationFilter および BasicAuthenticationEntryPoint を構成に追加します。後者は、フォームベースのログインが有効になっていない場合にのみ、構成エントリポイントとして使用されます。

<http-basic> の親要素
<http-basic> の属性
  • authentication-details-source-ref 認証フィルターによって使用される AuthenticationDetailsSource への参照
  • entry-point-refBasicAuthenticationFilter が使用する AuthenticationEntryPoint を設定します。

<http-firewall> 要素

これは、名前空間によって作成された FilterChainProxy に HttpFirewall のカスタム実装を挿入するために使用できる最上位要素です。デフォルトの実装は、ほとんどのアプリケーションに適しているはずです。

<http-firewall> の属性
  • refHttpFirewall を実装する Spring Bean への参照を定義します。

<intercept-url>

この要素は、アプリケーションが関心を持つ URL パターンのセットを定義し、それらの処理方法を構成するために使用されます。FilterSecurityInterceptor が使用する FilterInvocationSecurityMetadataSource を構築するために使用されます。たとえば、特定の URL に HTTPS でアクセスする必要がある場合は、ChannelProcessingFilter の構成も行います。指定されたパターンを受信リクエストと照合する場合、要素が宣言されている順序で照合が行われます。最も具体的なパターンを最初に、最も一般的なパターンを最後に配置する必要があります。

<intercept-url> の親要素
<intercept-url> の属性
  • access 定義された URL パターン / メソッドの組み合わせに対して FilterInvocationSecurityMetadataSource に保存されるアクセス属性をリストします。これは、セキュリティ構成属性(ロール名など)のコンマ区切りリストにする必要があります。
  • method 受信リクエストを照合するためにパターンおよびサーブレットパス(オプション)と組み合わせて使用される HTTP メソッド。省略した場合、どのメソッドも一致します。メソッドの有無にかかわらず同一のパターンが指定されている場合、メソッド固有の一致が優先されます。
  • pattern URL パスを定義するパターン。コンテンツは、含まれている http 要素の request-matcher 属性に依存するため、デフォルトでは ant パス構文になります。
  • request-matcher-ref この <intercept-url> が使用されているかどうかを判別するために使用される RequestMatcher への参照。
  • requires-channel 特定の URL パターンに HTTP または HTTPS のどちらでアクセスするかによって、「http」または「https」になります。または、優先度がない場合は、値「any」を使用できます。この属性が <intercept-url> 要素に存在する場合、ChannelProcessingFilter がフィルタースタックに追加され、その追加の依存関係がアプリケーションコンテキストに追加されます。

<port-mappings> 構成が追加されると、これは SecureChannelProcessor および InsecureChannelProcessor Bean によって使用され、HTTP/HTTPS へのリダイレクトに使用されるポートが決定されます。

[Note] メモ

このプロパティは、filter-security-metadata-source には無効です

  • servlet-path 受信リクエストを照合するためにパターンおよび HTTP メソッドと組み合わせて使用されるサーブレットパス。この属性は、request-matcher が「mvc」の場合にのみ適用できます。さらに、この値は、次の 2 つのユースケースでのみ必要です。1) '/' で始まるマッピングがあり、異なる HttpServlet が ServletContext に登録されている 2 つ以上があります。2)パターンは、デフォルト(ルート)の HttpServlet'/' を除いて、登録された HttpServlet パスと同じ値で始まります。
[Note] メモ

このプロパティは、filter-security-metadata-source には無効です

<jee>

J2eePreAuthenticatedProcessingFilter をフィルターチェーンに追加して、コンテナー認証との統合を提供します。

<jee> の親要素
<jee> 属性
  • mappable-roles 受信 HttpServletRequest で検索するロールのコンマ区切りリスト。
  • user-service-ref ユーザーサービス(または UserDetailsService Bean)ID への参照

<logout>

LogoutFilter をフィルタースタックに追加します。これは SecurityContextLogoutHandler で構成されます。

<logout> の親要素
<logout> の属性
  • delete-cookies ユーザーがログアウトするときに削除する必要がある Cookie の名前のコンマ区切りリスト。
  • invalidate-sessionSecurityContextLogoutHandler の invalidateHttpSession にマップします。デフォルトは「true」であるため、ログアウト時にセッションは無効になります。
  • logout-success-url ログアウト後にユーザーが表示されるリンク先 URL。デフォルトは <form-login-login-page> /?logout (つまり、/login?logout)

    この属性を設定すると、SessionManagementFilter に属性値で構成された SimpleRedirectInvalidSessionStrategy が挿入されます。無効なセッション ID が送信されると、戦略が呼び出され、構成された URL にリダイレクトされます。

  • logout-url ログアウトの原因となる URL(つまり、フィルターによって処理される URL)。デフォルトは「/logout」です。
  • success-handler-ref ログアウト後にナビゲーションを制御するために呼び出される LogoutSuccessHandler のインスタンスを提供するために使用できます。

<openid-login>

<form-login> に似ており、同じ属性があります。login-processing-url のデフォルト値は「/login/openid」です。OpenIDAuthenticationFilter と OpenIDAuthenticationProvider が登録されます。後者では、UserDetailsService への参照が必要です。繰り返しますが、これは user-service-ref 属性を使用して id で指定するか、アプリケーションコンテキストで自動的に配置されます。

<openid-login> の親要素
<openid-login> の属性
  • always-use-default-target ログイン後にユーザーを常に default-target-url にリダイレクトするかどうか。
  • authentication-details-source-ref 認証フィルターによって使用される AuthenticationDetailsSource への参照
  • authentication-failure-handler-ref 失敗した認証リクエストを処理するために使用される AuthenticationFailureHandler Bean への参照。実装は常に後続の宛先へのナビゲーションを処理する必要があるため、authentication-failure-url と組み合わせて使用しないでください。
  • authentication-failure-url ログイン失敗ページの URL。ログイン失敗 URL が指定されていない場合、Spring Security は /login?login_error で失敗ログイン URL と対応するフィルターを自動的に作成し、リクエスト時にそのログイン失敗 URL をレンダリングします。
  • authentication-success-forward-urlForwardAuthenticationSuccessHandler を UsernamePasswordAuthenticationFilter の authenticationSuccessHandler プロパティにマップします。
  • authentication-failure-forward-urlForwardAuthenticationFailureHandler を UsernamePasswordAuthenticationFilter の authenticationFailureHandler プロパティにマップします。
  • authentication-success-handler-ref 成功した認証リクエストを処理するために使用される AuthenticationSuccessHandler Bean への参照。実装は常に後続の宛先へのナビゲーションを処理する必要があるため、default-target-url (または always-use-default-target)と組み合わせて使用しないでください。
  • default-target-url ユーザーの前のアクションを再開できなかった場合に、認証が成功した後にリダイレクトされる URL。これは通常、ユーザーが最初に認証をトリガーする保護された操作をリクエストせずにログインページにアクセスした場合に発生します。指定しない場合、デフォルトでアプリケーションのルートになります。
  • login-page ログインページの URL。ログイン URL が指定されていない場合、Spring Security は /login でログイン URL と対応するフィルターを自動的に作成し、リクエストされたときにそのログイン URL をレンダリングします。
  • login-processing-url ログインフォームの投稿先の URL。指定しない場合、デフォルトは /login. になります
  • password-parameter パスワードを含むリクエストパラメーターの名前。デフォルトは「password」です。
  • user-service-ref ユーザーサービス(または UserDetailsService Bean)ID への参照
  • username-parameter ユーザー名を含むリクエストパラメーターの名前。デフォルトは「username」です。
<openid-login> の子要素

<attribute-exchange>

attribute-exchange 要素は、ID プロバイダーからリクエストされる属性のリストを定義します。例は、ネームスペース設定の章の OpenID サポートセクションにあります。複数を使用できます。その場合、それぞれに、指定された OpenID 識別子と一致する正規表現を含む identifier-match 属性が必要です。これにより、さまざまな属性リストをさまざまなプロバイダー(Google、Yahoo など)から取得できます。

<attribute-exchange> の親要素
<attribute-exchange> 属性
  • identifier-match 認証中に使用する属性交換構成を決定するときに、要求された ID と比較される正規表現。
<attribute-exchange> の子要素

<openid-attribute>

OpenID AX フェッチリクエスト (英語) を作成するときに使用される属性

<openid-attribute> の親要素
<openid-attribute> の属性
  • count 戻す属性の数を指定します。例: 3 通のメールを返します。デフォルト値は 1 です。
  • name 戻す属性の名前を指定します。例: メール。
  • required この属性が OP に必要かどうかを指定しますが、OP が属性を返さない場合でもエラーになりません。デフォルトは false です。

<port-mappings>

デフォルトでは、PortMapperImpl のインスタンスが設定に追加され、安全な URL と安全でない URL へのリダイレクトに使用されます。この要素は、そのクラスが定義するデフォルトのマッピングをオーバーライドするためにオプションで使用できます。各子 <port-mapping> 要素は、HTTP:HTTPS ポートのペアを定義します。デフォルトのマッピングは 80:443 および 8080:8443 です。これらをオーバーライドする例は、名前空間の導入にあります。

<port-mappings> の親要素
<port-mappings> の子要素

<port-mapping>

リダイレクトを強制するときに、http ポートを https ポートにマップする方法を提供します。

<port-mapping> の親要素
<port-mapping> の属性
  • http 使用する http ポート。
  • https 使用する https ポート。

<remember-me>

RememberMeAuthenticationFilter をスタックに追加します。これは、属性設定に応じて、TokenBasedRememberMeServicesPersistentTokenBasedRememberMeServices、または RememberMeServices を実装するユーザー指定の Bean で構成されます。

<remember-me> の親要素
<remember-me> 属性
  • authentication-success-handler-ref カスタムナビゲーションが必要な場合、RememberMeAuthenticationFilter の authenticationSuccessHandler プロパティを設定します。値は、アプリケーションコンテキストの AuthenticationSuccessHandler Bean の名前である必要があります。
  • data-source-refDataSource Bean への参照。これが設定されている場合、PersistentTokenBasedRememberMeServices が使用され、JdbcTokenRepositoryImpl インスタンスで構成されます。
  • remember-me-parameter remember-me 認証を切り替えるリクエストパラメーターの名前。デフォルトは「remember-me」です。AbstractRememberMeServices の「パラメーター」プロパティにマップします。
  • remember-me-cookie remember-me 認証用のトークンを保存する cookie の名前。デフォルトは「remember-me」です。AbstractRememberMeServices の「cookieName」プロパティにマップします。
  • keyAbstractRememberMeServices の「キー」プロパティにマップします。remember-me Cookie が 1 つのアプリケーション [16] 内でのみ有効になるように、固有の値に設定する必要があります。これが設定されていない場合、安全なランダム値が生成されます。安全なランダム値の生成には時間がかかることがあるため、この値を明示的に設定すると、remember-me 機能を使用する際の起動時間を改善できます。
  • services-alias 内部で定義された RememberMeServices を Bean エイリアスとしてエクスポートし、アプリケーションコンテキストの他の Bean で使用できるようにします。
  • services-ref フィルターによって使用される RememberMeServices 実装の完全な制御を許可します。値は、このインターフェースを実装するアプリケーションコンテキストの Bean の id である必要があります。ログアウトフィルターを使用している場合は、LogoutHandler も実装する必要があります。
  • token-repository-refPersistentTokenBasedRememberMeServices を構成しますが、カスタム PersistentTokenRepository Bean の使用を許可します。
  • token-validity-secondsAbstractRememberMeServices の tokenValiditySeconds プロパティにマップします。remember-me cookie を有効にする期間を秒単位で指定します。デフォルトでは、14 日間有効です。
  • use-secure-cookie remember-me Cookie は HTTPS 経由でのみ送信することをお勧めします。「secure」としてフラグを立てる必要があります。デフォルトでは、ログインリクエストが行われた接続が安全である場合(あるべき場合)、安全な Cookie が使用されます。このプロパティを false に設定すると、セキュア Cookie は使用されません。true に設定すると、Cookie に常にセキュアフラグが設定されます。この属性は、AbstractRememberMeServices の useSecureCookie プロパティにマップします。
  • user-service-ref remember-me サービスの実装には UserDetailsService へのアクセスが必要であるため、アプリケーションコンテキストで定義する必要があります。1 つしかない場合は、名前空間の構成によって自動的に選択および使用されます。複数のインスタンスがある場合、この属性を使用して Bean id を明示的に指定できます。

<request-cache> 要素

ExceptionTranslationFilter が AuthenticationEntryPoint を呼び出す前にリクエスト情報を格納するために使用する RequestCache インスタンスを設定します。

<request-cache> の親要素
<request-cache> の属性
  • refRequestCache である Spring Bean への参照を定義します。

<session-management>

セッション管理関連機能は、SessionManagementFilter をフィルタースタックに追加することで実装されます。

<session-management> の親要素
< セッション管理> 属性
  • invalid-session-url この属性を設定すると、SessionManagementFilter に属性値で構成された SimpleRedirectInvalidSessionStrategy が挿入されます。無効なセッション ID が送信されると、戦略が呼び出され、構成された URL にリダイレクトされます。
  • invalid-session-url SessionManagementFilter によって使用される InvalidSessionStrategy インスタンスの注入を許可します。これまたは invalid-session-url 属性のいずれかを使用しますが、両方は使用しません。
  • session-authentication-error-url SessionAuthenticationStrategy が例外を発生させたときに表示されるエラーページの URL を定義します。設定されていない場合、不正な (401) エラーコードがクライアントに返されます。認証が失敗した URL が優先されるフォームベースのログイン中にエラーが発生した場合、この属性は適用されないことに注意してください。
  • session-authentication-strategy-ref SessionManagementFilter によって使用される SessionAuthenticationStrategy インスタンスの注入を許可する
  • session-fixation-protection ユーザー認証時にセッション固定保護がどのように適用されるかを示します。「なし」に設定すると、保護は適用されません。「newSession」は、Spring セキュリティ関連の属性のみが移行された新しい空のセッションを作成します。「migrateSession」は、新しいセッションを作成し、すべてのセッション属性を新しいセッションにコピーします。Servlet 3.1(Java EE 7)以降のコンテナーでは、「changeSessionId」を指定すると、既存のセッションが保持され、コンテナー提供のセッション固定保護(HttpServletRequest#changeSessionId())が使用されます。Servlet 3.1 以降のコンテナーのデフォルトは「changeSessionId」、古いコンテナーの「migrateSession」です。「changeSessionId」が古いコンテナーで使用されている場合、例外をスローします。

    セッション固定保護が有効になっている場合、SessionManagementFilter には適切に構成された DefaultSessionAuthenticationStrategy が挿入されます。詳細については、このクラスの Javadoc を参照してください。

<session-management> の子要素

<concurrency-control>

同時セッション制御のサポートが追加され、ユーザーが持つことができるアクティブなセッションの数に制限を設けることができます。ConcurrentSessionFilter が作成され、ConcurrentSessionControlAuthenticationStrategy が SessionManagementFilter とともに使用されます。form-login 要素が宣言されている場合、戦略オブジェクトも作成された認証フィルターに挿入されます。SessionRegistry のインスタンス(ユーザーがカスタム Bean を使用することを望まない場合は SessionRegistryImpl インスタンス)は、戦略で使用するために作成されます。

<concurrency-control> の親要素
<concurrency-control> の属性
  • error-if-maximum-exceeded 「true」に設定すると、ユーザーがセッションの最大許容数を超えようとすると、SessionAuthenticationException が発生します。デフォルトの動作では、元のセッションが期限切れになります。
  • expired-url ユーザーが許可されたセッションの数を超えて別の場所に再度ログインしたため、同時セッションコントローラーによって「期限切れ」になったセッションを使用しようとすると、ユーザーがリダイレクトされる URL。exception-if-maximum-exceeded が設定されていない限り、設定する必要があります。値が指定されていない場合、有効期限メッセージがレスポンスに直接書き戻されます。
  • expired-url ConcurrentSessionFilter によって使用される ExpiredSessionStrategy インスタンスの注入を許可する
  • max-sessionsConcurrentSessionControlAuthenticationStrategy の maximumSessions プロパティにマップします。無制限のセッションをサポートするには、値として -1 を指定します。
  • session-registry-alias また、独自の Bean または管理インターフェースで使用するための内部セッションレジストリへの参照を持つことも役立ちます。session-registry-alias 属性を使用して内部 Bean を公開し、構成の他の場所で使用できる名前を付けることができます。
  • session-registry-ref ユーザーは、session-registry-ref 属性を使用して、独自の SessionRegistry 実装を提供できます。他の同時セッション制御 Bean は、それを使用するために接続されます。

<x509>

X.509 認証のサポートを追加します。X509AuthenticationFilter がスタックに追加され、Http403ForbiddenEntryPoint Bean が作成されます。後者は、他の認証メカニズムが使用されていない場合にのみ使用されます(その唯一の機能は HTTP 403 エラーコードを返すことです)。ユーザー権限のロードを UserDetailsService に委譲する PreAuthenticatedAuthenticationProvider も作成されます。

<x509> の親要素
<x509> の属性
  • authentication-details-source-refAuthenticationDetailsSource への参照
  • subject-principal-regex 証明書からユーザー名を抽出するために使用される正規表現を定義します(UserDetailsService で使用するため)。
  • user-service-ref 複数のインスタンスが構成されている場合に、特定の UserDetailsService を X.509 で使用できます。設定されていない場合は、適切なインスタンスを自動的に見つけて使用しようとします。

<filter-chain-map>

FilterChainProxy インスタンスを FilterChainMap で明示的に構成するために使用されます

<filter-chain-map> の属性
  • request-matcher 受信リクエストの照合に使用する戦略を定義します。現在、オプションは 'ant' (ant パスパターン用)、正規表現用の 'regex'、大文字と小文字を区別しない正規表現用の 'ciRegex' です。
<filter-chain-map> の子要素

<filter-chain>

内で使用され、特定の URL パターンと、そのパターンに一致する URL に適用されるフィルターのリストを定義します。FilterChainProxy を構成するために複数のフィルターチェーン要素がリストにアセンブルされる場合、最も具体的なパターンをリストの一番上に配置し、最も一般的なパターンを一番下に配置する必要があります。

<filter-chain> の親要素
<filter-chain> 属性
  • filtersFilter を実装する Spring Bean への参照のコンマ区切りリスト。値「none」は、この FilterChain に Filter を使用しないことを意味します。
  • request-matcher-reffilters 属性から Filter を呼び出す必要があるかどうかを判別するために使用される RequestMatcher への参照。

<filter-security-metadata-source>

FilterSecurityInterceptor で使用するために FilterSecurityMetadataSource Bean を明示的に構成するために使用されます。通常、<http> 要素を使用するのではなく、FilterChainProxy を明示的に構成する場合にのみ必要です。使用する intercept-url 要素には、パターン、メソッド、アクセス属性のみを含める必要があります。それ以外の場合は、構成エラーが発生します。

<filter-security-metadata-source> の属性
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • request-matcher 受信リクエストのマッチングに使用する戦略を定義します。現在、オプションは 'ant' (ant パスパターン用)、正規表現用の 'regex'、大文字と小文字を区別しない正規表現用の 'ciRegex' です。
  • use-expressions 従来の構成属性のリストではなく、<intercept-url> 要素の「access」属性で式を使用できるようにします。デフォルトは「true」です。有効にした場合、各属性には単一のブール式を含める必要があります。式が「true」と評価されると、アクセスが許可されます。
<filter-security-metadata-source> の子要素

20.2.2 WebSocket セキュリティ

Spring Security 4.0+ は、メッセージの認可をサポートします。これが有用である具体的な例の 1 つは、WebSocket ベースのアプリケーションで認可を提供することです。

<websocket-message-broker>

websocket-message-broker 要素には 2 つの異なるモードがあります。[ メール保護 ] が指定されていない場合、次のことを行います。

  • SimpAnnotationMethodMessageHandler に AuthenticationPrincipalArgumentResolver がカスタム引数リゾルバーとして登録されていることを確認してください。これにより、@AuthenticationPrincipal を使用して現在の Authentication のプリンシパルを解決できます。
  • SecurityContextChannelInterceptor が clientInboundChannel に自動的に登録されるようにします。これにより、SecurityContextHolder にメッセージで見つかったユーザーが入力されます
  • ChannelSecurityInterceptor が clientInboundChannel に登録されていることを確認します。これにより、認可ルールをメッセージに指定できます。
  • CsrfChannelInterceptor が clientInboundChannel に登録されていることを確認します。これにより、元のドメインからのリクエストのみが有効になります。
  • CsrfTokenHandshakeInterceptor が WebSocketHttpRequestHandler、TransportHandlingSockJsService、または DefaultSockJsService に登録されていることを確認します。これにより、HttpServletRequest から予想される CsrfToken が WebSocket セッション属性にコピーされます。

追加の制御が必要な場合、ID を指定でき、ChannelSecurityInterceptor が指定された ID に割り当てられます。その後、Spring のメッセージングインフラストラクチャとのすべての接続を手動で行うことができます。これは面倒ですが、構成をより細かく制御できます。

<websocket-message-broker> の属性
  • id Bean 識別子。コンテキストの他の場所で ChannelSecurityInterceptor Bean を参照するために使用されます。指定した場合、Spring Security は Spring メッセージング内で明示的な構成を必要とします。指定しない場合、Spring Security は、「<websocket-message-broker>」で説明されているように、 メッセージングインフラストラクチャと自動的に統合されます。
  • same-origin-disabled CSRF トークンが Stomp ヘッダーに存在するという要件を無効にします(デフォルトは false)。デフォルトの変更は、他のオリジンが SockJS 接続を確立できるようにする必要がある場合に役立ちます。
<websocket-message-broker> の子要素

<intercept-message>

メッセージの認可規則を定義します。

<intercept-message> の親要素
<intercept-message> の属性
  • pattern メッセージの宛先に一致する ant ベースのパターン。例: 「/ " は、宛先を持つすべてのメッセージに一致します。;" /admin/ 」は、宛先が「/admin/**」で始まるすべてのメッセージに一致します。
  • type 照合するメッセージのタイプ。有効な値は SimpMessageType で定義されています(つまり、CONNECT、CONNECT_ACK、HEARTBEAT、MESSAGE、SUBSCRIBE、UNSUBSCRIBE、DISCONNECT、DISCONNECT_ACK、OTHER)。
  • access メッセージの保護に使用される式。例: 「denyAll」は、一致するすべてのメッセージへのアクセスを拒否します。「permitAll」は、一致するすべてのメッセージへのアクセスを許可します。「hasRole('ADMIN' )では、現在のユーザーが一致するメッセージのロール「ROLE_ADMIN」を持っている必要があります。

20.2.3 認証サービス

Spring Security 3.0 より前は、AuthenticationManager が内部で自動的に登録されていました。ここで、<authentication-manager> 要素を使用して明示的に登録する必要があります。これにより、Spring Security の ProviderManager クラスのインスタンスが作成されます。これは、1 つ以上の AuthenticationProvider インスタンスのリストで構成する必要があります。これらは、名前空間によって提供される構文要素を使用して作成するか、authentication-provider 要素を使用してリストに追加するようにマークされた標準の Bean 定義にすることができます。

<authentication-manager>

名前空間を使用するすべての Spring Security アプリケーションには、この要素をどこかに含める必要があります。アプリケーションに認証サービスを提供する AuthenticationManager の登録を担当します。AuthenticationProvider インスタンスを作成するすべての要素は、この要素の子でなければなりません。

<authentication-manager> 属性
  • alias この属性を使用すると、独自の構成で使用する内部インスタンスのエイリアス名を定義できます。その使用箇所は、名前空間の導入で説明されています。
  • erase-credentials true に設定されている場合、AuthenticationManager は、ユーザーが認証されると、返された Authentication オブジェクトの資格情報データをクリアしようとします。文字通り、ProviderManager の eraseCredentialsAfterAuthentication プロパティにマップします。これについては、コアサービスの章で説明しています。
  • id この属性を使用すると、独自の構成で使用する内部インスタンスの ID を定義できます。これは alias 要素と同じですが、id 属性を使用する要素でより一貫したエクスペリエンスを提供します。
<authentication-manager> の子要素

<authentication-provider>

ref 属性で使用しない限り、この要素は DaoAuthenticationProvider を構成するための略記です。DaoAuthenticationProvider は UserDetailsService からユーザー情報をロードし、ユーザー名 / パスワードの組み合わせをログイン時に提供された値と比較します。UserDetailsService インスタンスは、使用可能な名前空間要素を使用して定義できます(jdbc-user-service または user-service-ref 属性を使用して、アプリケーションコンテキストの他の場所で定義された Bean を指す)。これらのバリエーションの例は、ネームスペースの導入にあります。

<authentication-provider> の親要素
<authentication-provider> 属性
  • refAuthenticationProvider を実装する Spring Bean への参照を定義します。

独自の AuthenticationProvider 実装を作成した場合(または、何らかの理由で Spring Security の実装の 1 つを従来の Bean として構成したい場合は、次の構文を使用して ProviderManager の内部リストに追加できます。

<security:authentication-manager>
<security:authentication-provider ref="myAuthenticationProvider" />
</security:authentication-manager>
<bean id="myAuthenticationProvider" class="com.something.MyAuthenticationProvider"/>
  • user-service-ref UserDetailsService を実装する Bean への参照。標準の Bean 要素またはカスタムユーザーサービス要素を使用して作成できます。

<jdbc-user-service>

JDBC ベースの UserDetailsService を作成します。

<jdbc-user-service> の属性
  • authorities-by-username-query ユーザー名を指定してユーザーに付与された権限を照会する SQL ステートメント。

デフォルトは

select username, authority from authorities where username = ?
  • cache-ref UserDetailsService で使用するキャッシュへの参照を定義します。
  • data-source-ref 必要なテーブルを提供する DataSource の Bean ID。
  • group-authorities-by-username-query ユーザー名を指定してユーザーのグループ権限を照会する SQL ステートメント。デフォルトは

    select
    g.id, g.group_name, ga.authority
    from
    groups g, group_members gm, group_authorities ga
    where
    gm.username = ? and g.id = ga.group_id and g.id = gm.group_id
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • role-prefix 永続ストレージからロードされるロール文字列に追加される空でない文字列プレフィックス(デフォルトは「ROLE_」)。デフォルトが空でない場合、プレフィックスなしの場合は値「none」を使用します。
  • users-by-username-query ユーザー名、パスワード、ユーザー名を指定した有効なステータスを照会する SQL ステートメント。デフォルトは

    select username, password, enabled from users where username = ?

<password-encoder>

オプションで、ネームスペースの概要で説明されているパスワードエンコーダを使用するように認証プロバイダを構成できます。これにより、Bean に適切な PasswordEncoder インスタンスが挿入されます。

<password-encoder> の親要素
<password-encoder> 属性
  • hash ユーザーパスワードで使用されるハッシュアルゴリズムを定義します。MD4 は非常に弱いハッシュアルゴリズムであるため、MD4 の使用は強くお勧めします。
  • refPasswordEncoder を実装する Spring Bean への参照を定義します。

<user-service>

プロパティファイルまたは「ユーザー」子要素のリストからメモリ内 UserDetailsService を作成します。ユーザー名は、大文字と小文字を区別しない検索を可能にするために内部的に小文字に変換されるため、大文字と小文字を区別する必要がある場合は使用しないでください。

<user-service> の属性
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • properties 各行が次の形式であるプロパティファイルの場所

    username=password,grantedAuthority[,grantedAuthority][,enabled|disabled]
<user-service> の子要素

<user>

アプリケーション内のユーザーを表します。

<user> の親要素
<user> 属性
  • authorities ユーザーに付与された 1 つ以上の権限。権限をコンマで区切ります(スペースは入れません)。例: "ROLE_USER、ROLE_ADMINISTRATOR"
  • disabled アカウントを無効かつ使用不可としてマークするには、「true」に設定できます。
  • locked 「true」に設定して、アカウントをロック済みで使用不可としてマークできます。
  • name ユーザーに割り当てられたユーザー名。
  • password ユーザーに割り当てられたパスワード。対応する認証プロバイダーがハッシュをサポートしている場合、これをハッシュすることができます("user-service" 要素の "hash" 属性を設定することを忘れないでください)。データが認証に使用されず、アクセス権限にのみ使用される場合、この属性は省略されます。省略した場合、名前空間はランダムな値を生成し、認証のために誤って使用されるのを防ぎます。空にすることはできません。

20.2.4 メソッドのセキュリティ

<global-method-security>

この要素は、Spring Security Bean のメソッドを保護するためのサポートを追加する主な手段です。メソッドは、アノテーション(インターフェースまたはクラスレベルで定義)を使用するか、AspectJ 構文を使用して一連のポイントカットを子要素として定義することで保護できます。

<global-method-security> の属性
  • access-decision-manager-ref メソッドセキュリティは Web セキュリティと同じ AccessDecisionManager 構成を使用しますが、この属性を使用してこれをオーバーライドできます。デフォルトでは、AffirmativeBased 実装は RoleVoter および AuthenticatedVoter で使用されます。
  • authentication-manager-ref メソッドのセキュリティに使用される AuthenticationManager への参照。
  • jsr250-annotations JSR-250 スタイル属性を使用するかどうかを指定します(たとえば、「RolesAllowed」)。これには、クラスパスに javax.annotation.security クラスが必要です。これを true に設定すると、Jsr250Voter が AccessDecisionManager に追加されるため、カスタム実装を使用していてこれらのアノテーションを使用する場合は、これを行う必要があります。
  • metadata-source-ref 他のソース(デフォルトのアノテーションなど)よりも優先される外部 MethodSecurityMetadataSource インスタンスを提供できます。
  • mode この属性を「aspectj」に設定して、デフォルトの Spring AOP の代わりに AspectJ を使用することを指定できます。protected メソッドは、spring-security-aspects モジュールの AnnotationSecurityAspect で織る必要があります。

AspectJ は、インターフェースのアノテーションは継承されないという Java のルールに従っていることに注意することが重要です。これは、インターフェースでセキュリティアノテーションを定義するメソッドが保護されないことを意味します。代わりに、AspectJ を使用するときにクラスに Security アノテーションを配置する必要があります。

  • order メソッドセキュリティインターセプタに対してアドバイス「order」を設定できます。
  • pre-post-annotations Spring Security の呼び出し前アノテーションと呼び出し後アノテーション(@PreFilter、@PreAuthorize、@PostFilter、@PostAuthorize)の使用をこのアプリケーションコンテキストで有効にするかどうかを指定します。デフォルトは「無効」です。
  • proxy-target-class true の場合、インターフェースベースのプロキシの代わりにクラスベースのプロキシが使用されます。
  • run-as-manager-ref 設定された MethodSecurityInterceptor によって使用されるオプションの RunAsManager 実装への参照
  • secured-annotations Spring Security の @Secured アノテーションの使用をこのアプリケーションコンテキストで有効にするかどうかを指定します。デフォルトは「無効」です。

<after-invocation-provider>

この要素は、<global-method-security> 名前空間によって維持されるセキュリティインターセプターが使用するために AfterInvocationProvider を修飾するために使用できます。global-method-security 要素内でこれらの 0 個以上を定義でき、それぞれがアプリケーションコンテキスト内の AfterInvocationProvider Bean インスタンスを指す ref 属性を持ちます。

<after-invocation-provider> の親要素
<after-invocation-provider> 属性
  • refAfterInvocationProvider を実装する Spring Bean への参照を定義します。

<pre-post-annotation-handling>

Spring Security の呼び出し前および呼び出し後のアノテーション(@PreFilter、@PreAuthorize、@PostFilter、@PostAuthorize)を処理するためのデフォルトの式ベースのメカニズムを完全に置き換えることができます。これらのアノテーションが有効な場合にのみ適用されます。

<pre-post-annotation-handling> の親要素

<invocation-attribute-factory>

アノテーション付きメソッドから事前呼び出しおよびリアクティブ呼び出しのメタデータを生成するために使用される PrePostInvocationAttributeFactory インスタンスを定義します。

<invocation-attribute-factory> の親要素
<invocation-attribute-factory> 属性
  • ref Spring Bean ID への参照を定義します。

<post-invocation-advice>

PostInvocationAdviceProvider を ref で PostInvocationAuthorizationAdvice としてカスタマイズして、<pre-post-annotation-handling> 素子。

<post-invocation-advice> の親要素
<post-invocation-advice> の属性
  • ref Spring Bean ID への参照を定義します。

<pre-invocation-advice>

PreInvocationAuthorizationAdviceVoter を ref で PreInvocationAuthorizationAdviceVoter としてカスタマイズして、<pre-post-annotation-handling> 素子。

<pre-invocation-advice> の親要素
<pre-invocation-advice> 属性
  • ref Spring Bean ID への参照を定義します。

メソッドの保護

<protect-pointcut>  @Secured アノテーションを使用して個々のメソッドまたはクラスベースでセキュリティ属性を定義するのではなく、<protect-pointcut> 要素を使用して、サービスレイヤーのメソッドとインターフェースのセット全体に横断的なセキュリティ制約を定義できます。名前空間の導入で例を見つけることができます。

<protect-pointcut> の親要素
<protect-pointcut> の属性
  • access ポイントカットに一致するすべてのメソッドに適用される構成属性リストにアクセスします。「ROLE_A、ROLE_B」
  • expression 'execution' キーワードを含む AspectJ 式。例: 'execution(int com.foo.TargetObject.countLength(String))'(引用符なし)。

<intercept-methods>

Bean 定義内で使用して、セキュリティインターセプターを Bean に追加し、Bean のメソッドのアクセス構成属性を設定できます。

<intercept-methods> の属性
  • access-decision-manager-ref 作成されたメソッドセキュリティインターセプターが使用するオプションの AccessDecisionManager Bean ID。
<intercept-methods> の子要素

<method-security-metadata-source>

MethodSecurityMetadataSource インスタンスを作成する

<method-security-metadata-source> の属性
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • use-expressions 従来の構成属性のリストではなく、<intercept-url> 要素の「access」属性で式を使用できるようにします。デフォルトは「false」です。有効にした場合、各属性には単一のブール式を含める必要があります。式が「true」と評価されると、アクセスが許可されます。
<method-security-metadata-source> の子要素

<protect>

protected メソッドとそれに適用されるアクセス制御構成属性を定義します。「global-method-security」で提供されるサービスに「protect」宣言を混在させないことを強くお勧めします。

<protect> 属性
  • access メソッドに適用されるアクセス構成属性リスト。「ROLE_A、ROLE_B」。
  • method メソッド名

20.2.5 LDAP 名前空間オプション

LDAP については、独自の章で詳細を説明しています。ここで、名前空間オプションが Spring Bean にどのようにマップされるかについて説明しながら、これを拡張します。LDAP 実装では Spring LDAP を広範囲に使用しているため、そのプロジェクトの API にある程度精通していると役立つ場合があります。

LDAP サーバーの定義

<ldap-server> 要素この要素は、他の LDAP Bean が使用する Spring LDAP ContextSource をセットアップし、LDAP サーバーの場所と、接続するためのその他の情報(匿名アクセスを許可しない場合はユーザー名とパスワードなど)を定義します。また、テスト用の組み込みサーバーの作成にも使用できます。両方のオプションの構文の詳細は、LDAP の章で説明されています。実際の ContextSource 実装は、Spring LDAP の LdapContextSource クラスを継承する DefaultSpringSecurityContextSource です。manager-dn および manager-password 属性は、後者の userDn および password プロパティにそれぞれマッピングされます。

アプリケーションコンテキストで 1 つのサーバーのみが定義されている場合、他の LDAP 名前空間で定義された Bean はそれを自動的に使用します。それ以外の場合は、要素に "id" 属性を与え、server-ref 属性を使用して他のネームスペース Bean からそれを参照できます。他の従来の Spring Bean で使用する場合、これは実際には ContextSource インスタンスの Bean id です。

<ldap-server> の属性
  • mode 使用する組み込み LDAP サーバーを明示的に指定します。値は apacheds および unboundid です。デフォルトでは、ライブラリがクラスパスで利用可能かどうかに依存します。
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • ldif 組み込み LDAP サーバーにロードする ldif ファイルリソースを明示的に指定します。ldif は Spring リソースパターン(つまり、classpath:init.ldif)でなければなりません。デフォルトは classpath *:*.ldif です
  • manager-dn (埋め込みでない)LDAP サーバーへの認証に使用される「マネージャー」ユーザー ID のユーザー名(DN)。省略すると、匿名アクセスが使用されます。
  • manager-password マネージャー DN のパスワード。これは、manager-dn が指定されている場合に必要です。
  • port IP ポート番号を指定します。たとえば、組み込み LDAP サーバーの構成に使用されます。デフォルト値は 33389 です。
  • root 組み込み LDAP サーバーのオプションのルートサフィックス。デフォルトは「dc = springframework、dc = org」です
  • url 組み込み LDAP サーバーを使用しない場合、LDAP サーバーの URL を指定します。

<ldap-authentication-provider>

この要素は、LdapAuthenticationProvider インスタンスの作成の略記です。デフォルトでは、これは BindAuthenticator インスタンスと DefaultAuthoritiesPopulator で構成されます。すべての名前空間認証プロバイダーと同様に、authentication-provider 要素の子として含める必要があります。

<ldap-authentication-provider> の親要素
<ldap-authentication-provider> の属性
  • group-role-attribute Spring Security 内で使用されるロール名を含む LDAP 属性名。DefaultLdapAuthoritiesPopulator の groupRoleAttribute プロパティにマップします。デフォルトは「cn」です。
  • group-search-base グループメンバーシップ検索の検索ベース。DefaultLdapAuthoritiesPopulator の groupSearchBase コンストラクター引数にマップします。デフォルトは ""(ルートから検索)です。
  • group-search-filter グループ検索フィルター。DefaultLdapAuthoritiesPopulator の groupSearchFilter プロパティにマップします。デフォルトは (uniqueMember={0}) です。置換パラメーターは、ユーザーの DN です。
  • role-prefix 永続からロードされるロール文字列に追加される空でない文字列プレフィックス。DefaultLdapAuthoritiesPopulator の rolePrefix プロパティにマップします。デフォルトは「ROLE_」です。デフォルトが空でない場合、プレフィックスなしの場合は値「none」を使用します。
  • server-ref 使用するオプションのサーバー。省略すると、デフォルトの LDAP サーバーが登録され(ID なしで <ldap-server> を使用)、そのサーバーが使用されます。
  • user-context-mapper-ref ユーザーのディレクトリエントリのコンテキスト情報で呼び出される UserDetailsContextMapper Bean を指定することにより、ロードされたユーザーオブジェクトの明示的なカスタマイズを許可します。
  • user-details-class ユーザーエントリの objectClass を指定できます。設定されている場合、フレームワークは定義されたクラスの標準属性を返された UserDetails オブジェクトにロードしようとします
  • user-dn-pattern ユーザーがディレクトリ内の固定された場所にいる場合(つまり、ディレクトリ検索を行わずにユーザー名から DN を直接計算できる場合)、この属性を使用して DN に直接マッピングできます。AbstractLdapAuthenticator の userDnPatterns プロパティに直接マップします。値は、"uid={0},ou=people" など、ユーザーの DN の作成に使用される特定のパターンです。キー "{0}" が存在する必要があり、ユーザー名に置き換えられます。
  • user-search-base ユーザー検索の検索ベース。デフォルトは "" です。「user-search-filter」でのみ使用されます。

    ディレクトリ内でユーザーを見つけるために検索を実行する必要がある場合は、これらの属性を設定して検索を制御できます。BindAuthenticator は FilterBasedLdapUserSearch で構成され、属性値はその Bean のコンストラクターの最初の 2 つの引数に直接マップされます。これらの属性が設定されておらず、代替として user-dn-pattern が提供されていない場合、user-search-filter="(uid={0})" および user-search-base="" のデフォルトの検索値が使用されます。

  • user-search-filter ユーザーの検索に使用される LDAP フィルター(オプション)。たとえば、"(uid={0})"。置換されたパラメーターは、ユーザーのログイン名です。

    ディレクトリ内でユーザーを見つけるために検索を実行する必要がある場合は、これらの属性を設定して検索を制御できます。BindAuthenticator は FilterBasedLdapUserSearch で構成され、属性値はその Bean のコンストラクターの最初の 2 つの引数に直接マップされます。これらの属性が設定されておらず、代替として user-dn-pattern が提供されていない場合、user-search-filter="(uid={0})" および user-search-base="" のデフォルトの検索値が使用されます。

<ldap-authentication-provider> の子要素

<password-compare>

これは、<ldap-provider> の子要素として使用され、認証戦略を BindAuthenticator から PasswordComparisonAuthenticator に切り替えます。

<password-compare> の親要素
<password-compare> の属性
  • hash ユーザーパスワードで使用されるハッシュアルゴリズムを定義します。MD4 は非常に弱いハッシュアルゴリズムであるため、MD4 の使用は強くお勧めします。
  • password-attribute ユーザーパスワードを含むディレクトリ内の属性。デフォルトは「userPassword」です。
<password-compare> の子要素

<ldap-user-service>

この要素は、LDAP UserDetailsService を構成します。使用されるクラスは、FilterBasedLdapUserSearch と DefaultLdapAuthoritiesPopulator の組み合わせである LdapUserDetailsService です。サポートする属性には、<ldap-provider> と同じ使用箇所があります。

<ldap-user-service> の属性
  • cache-ref UserDetailsService で使用するキャッシュへの参照を定義します。
  • group-role-attribute Spring Security 内で使用されるロール名を含む LDAP 属性名。デフォルトは「cn」です。
  • group-search-base グループメンバーシップ検索の検索ベース。デフォルトは ""(ルートから検索)です。
  • group-search-filter グループ検索フィルター。デフォルトは (uniqueMember={0}) です。置換パラメーターは、ユーザーの DN です。
  • id Bean 識別子。コンテキストの他の場所で Bean を参照するために使用されます。
  • role-prefix 永続ストレージからロードされたロール文字列に追加される空でない文字列プレフィックス(「ROLE_」など)。デフォルトが空でない場合、プレフィックスなしの場合は値「none」を使用します。
  • server-ref 使用するオプションのサーバー。省略すると、デフォルトの LDAP サーバーが登録され(ID なしで <ldap-server> を使用)、そのサーバーが使用されます。
  • user-context-mapper-ref ユーザーのディレクトリエントリのコンテキスト情報で呼び出される UserDetailsContextMapper Bean を指定することにより、ロードされたユーザーオブジェクトの明示的なカスタマイズを許可します。
  • user-details-class ユーザーエントリの objectClass を指定できます。設定されている場合、フレームワークは定義されたクラスの標準属性を返された UserDetails オブジェクトにロードしようとします
  • user-search-base ユーザー検索の検索ベース。デフォルトは "" です。「user-search-filter」でのみ使用されます。
  • user-search-filter ユーザーの検索に使用される LDAP フィルター(オプション)。たとえば、"(uid={0})"。置換されたパラメーターは、ユーザーのログイン名です。

20.3 Spring Security の依存関係

この付録では、Spring Security のモジュールのリファレンスと、実行中のアプリケーションで機能するために必要な追加の依存関係を提供します。Spring Security 自体をビルドまたはテストするときにのみ使用される依存関係は含まれません。また、外部の依存関係で必要とされる推移的な依存関係も含めません。

必要な Spring のバージョンはプロジェクト Web サイトにリストされているため、以下の Spring 依存関係の特定のバージョンは省略されています。以下に「オプション」としてリストされている依存関係の一部は、Spring アプリケーションのその他の非セキュリティ機能に必要な場合があることに注意してください。また、「オプション」としてリストされている依存関係は、ほとんどのアプリケーションで使用されている場合、実際にはプロジェクトの Maven POM ファイルでそのようにマークされない場合があります。指定された機能を使用しない限り、それらは必要ないという意味でのみ「オプション」です。

モジュールが別の Spring Security モジュールに依存している場合、依存するモジュールのオプションではない依存関係も必須であると想定され、個別にリストされていません。

20.3.1 spring-security-core

Spring Security を使用するプロジェクトには、コアモジュールを含める必要があります。

テーブル 20.1: コアの依存関係

依存 バージョン 説明

ehcache

1.6.2

Ehcache ベースのユーザーキャッシュ実装を使用する場合は必須です(オプション)。

spring-aop

メソッドセキュリティは Spring AOP に基づいています

spring-beans

Spring 構成に必要

spring-expression

式ベースのメソッドセキュリティに必要 (オプション)

spring-jdbc

データベースを使用してユーザーデータを保存する場合は必須です(オプション)。

spring-tx

データベースを使用してユーザーデータを保存する場合は必須です(オプション)。

aspectjrt

1.6.10

AspectJ サポートを使用する場合は必須です(オプション)。

jsr250-api

1.0

JSR-250 メソッドセキュリティアノテーションを使用している場合は必須です(オプション)。


20.3.2 spring-security-remoting

このモジュールは通常、サーブレット API を使用する Web アプリケーションで必要です。

テーブル 20.2: リモーティングの依存関係

依存 バージョン 説明

spring-security-core

spring-web

HTTP リモーティングサポートを使用するクライアントに必要です。


20.3.3 spring-security-web

このモジュールは通常、サーブレット API を使用する Web アプリケーションで必要です。

テーブル 20.3: Web の依存関係

依存 バージョン 説明

spring-security-core

spring-web

Spring Web サポートクラスは広く使用されています。

spring-jdbc

JDBC ベースの永続的な remember-me トークンリポジトリに必要です(オプション)。

spring-tx

remember-me 永久トークンリポジトリの実装に必要です(オプション)。


20.3.4 spring-security-ldap

このモジュールは、LDAP 認証を使用している場合にのみ必要です。

テーブル 20.4: LDAP の依存関係

依存 バージョン 説明

spring-security-core

spring-ldap-core

1.3.0

LDAP サポートは Spring LDAP に基づいています。

spring-tx

データ例外クラスが必要です。

apache-ds [1]

1.5.5

組み込み LDAP サーバーを使用している場合は必須です(オプション)。

shared-ldap

0.9.15

組み込み LDAP サーバーを使用している場合は必須です(オプション)。

ldapsdk

4.1

Mozilla LdapSDK。たとえば、OpenLDAP でパスワードポリシー機能を使用している場合、LDAP パスワードポリシーコントロールのデコードに使用されます。

[1] モジュール apacheds-coreapacheds-core-entryapacheds-protocol-sharedapacheds-protocol-ldapapacheds-server-jndi が必要です。


20.3.5 spring-security-config

Spring Security 名前空間構成を使用している場合、このモジュールは必須です。

テーブル 20.5: 構成の依存関係

依存 バージョン 説明

spring-security-core

spring-security-web

Web 関連のネームスペース構成を使用している場合は必須です(オプション)。

spring-security-ldap

LDAP 名前空間オプションを使用している場合は必須です(オプション)。

spring-security-openid

OpenID 認証を使用している場合は必須です(オプション)。

アスペクト

1.6.10

protect-pointcut 名前空間構文を使用する場合は必須です(オプション)。


20.3.6 spring-security-acl

ACL モジュール。

テーブル 20.6: ACL の依存関係

依存 バージョン 説明

spring-security-core

ehcache

1.6.2

Ehcache ベースの ACL キャッシュ実装を使用する場合は必須です(独自の実装を使用する場合はオプション)。

spring-jdbc

デフォルトの JDBC ベースの AclService を使用している場合は必須です(独自に実装する場合はオプション)。

spring-tx

デフォルトの JDBC ベースの AclService を使用している場合は必須です(独自に実装する場合はオプション)。


20.3.7 spring-security-cas

CAS モジュールは、JA-SIG CAS との統合を提供します。

テーブル 20.7: CAS の依存関係

依存 バージョン 説明

spring-security-core

spring-security-web

cas-client-core

3.1.12

JA-SIG CAS クライアント。これが Spring Security 統合の基礎です。

ehcache

1.6.2

Ehcache ベースのチケットキャッシュを使用している場合は必須です(オプション)。


20.3.8 spring-security-openid

OpenID モジュール。

テーブル 20.8: OpenID の依存関係

依存 バージョン 説明

spring-security-core

spring-security-web

openid4java-nodeps

0.9.6

Spring Security の OpenID 統合は OpenID4Java を使用します。

httpclient

4.1.1

openid4java-nodeps は HttpClient 4 に依存しています。

guice

2.0

openid4java-nodeps は Guice 2 に依存しています。


20.3.9 spring-security-taglibs

Spring Security の JSP タグの実装を提供します。

テーブル 20.9: Taglib の依存関係

依存 バージョン 説明

spring-security-core

spring-security-web

spring-security-acl

ACL で accesscontrollist タグまたは hasPermission() 式を使用している場合は必須です(オプション)。

spring-expression

タグアクセス制約で SPEL 式を使用している場合は必須です。


20.4 Spring Security FAQ

20.4.1 一般的な質問

Spring Security はすべてのアプリケーションセキュリティ要件を処理しますか?

Spring Security は、認証と認可の要件に対して非常に柔軟なフレームワークを提供しますが、その範囲外にある安全なアプリケーションを構築するためには、他にも多くの考慮事項があります。Web アプリケーションは、できれば開発を開始する前に、慣れ親しんでおくべきあらゆる種類の攻撃に対して脆弱であるため、最初から念頭に置いて設計およびコーディングできます。Web アプリケーション開発者が直面している主要な課題とそれらに対して使用できる対策に関する情報については、http://www.owasp.org/[OWASP Web サイトを参照してください。

web.xml セキュリティを使用しないのはなぜですか?

Spring に基づいたエンタープライズアプリケーションを開発していると仮定しましょう。通常、対処する必要があるセキュリティ上の懸念は 4 つあります: 認証、Web リクエストセキュリティ、サービスレイヤーセキュリティ(ビジネスロジックを実装するメソッド)、およびドメインオブジェクトインスタンスセキュリティ(つまり、異なるドメインオブジェクトには異なるアクセス許可があります)。これらの典型的な要件を念頭に置いて:

  1. 認証 : サーブレット仕様は、認証へのアプローチを提供します。ただし、通常はコンテナー固有の「レルム」設定の編集が必要な認証を実行するようにコンテナーを構成する必要があります。これにより、移植性のない構成になり、コンテナーの認証インターフェースを実装するために実際の Java クラスを記述する必要がある場合、さらに移植性のないものになります。Spring Security を使用すると、WAR レベルまで完全な移植性を実現できます。また、Spring Security は、実績のある認証プロバイダーとメカニズムの選択肢を提供します。つまり、デプロイ時に認証アプローチを切り替えることができます。これは、未知のターゲット環境で動作する必要がある製品を作成するソフトウェアベンダーにとって特に価値があります。
  2. Web リクエストセキュリティ : サーブレット仕様は、リクエスト URI を保護するアプローチを提供します。ただし、これらの URI は、サーブレット仕様自体の制限された URI パス形式でのみ表現できます。Spring Security は、はるかに包括的なアプローチを提供します。たとえば、Ant パスまたは正規表現を使用でき、単にリクエストされたページ以外の URI の部分を考慮することができ(たとえば、HTTP GET パラメーターを考慮することができます)、構成データの独自のランタイムソースを実装できます。つまり、webapp の実際の実行中に、Web リクエストのセキュリティを動的に変更できます。
  3. サービス層とドメインオブジェクトのセキュリティ : サービス層セキュリティまたはドメインオブジェクトインスタンスセキュリティのサーブレット仕様にサポートがないことは、多層アプリケーションの重大な制限を表しています。通常、開発者はこれらの要件を無視するか、MVC コントローラーコード内(またはさらに悪いことにビュー内)にセキュリティロジックを実装します。このアプローチには重大な欠点があります。

    1. 関心事の分離 : 認可は横断的な懸念事項であり、そのように実装する必要があります。認可コードを実装する MVC コントローラーまたはビューは、コントローラーと認可ロジックの両方をテストすることをより困難にし、デバッグすることをより難しくし、多くの場合、コードの重複につながります。
    2. リッチクライアントと Web サービスのサポート : 追加のクライアント型を最終的にサポートする必要がある場合、Web レイヤーに埋め込まれた認証コードは再利用できません。Spring リモーティングエクスポーターは、サービスレイヤー Bean のみをエクスポートする(MVC コントローラーはエクスポートしない)ことを考慮する必要があります。そのため、多数のクライアント型をサポートするには、サービスレイヤーに認証ロジックを配置する必要があります。
    3. 階層化の課題 : MVC コントローラーまたはビューは、サービスレイヤーメソッドまたはドメインオブジェクトインスタンスに関する認可決定を実装するための、単に誤ったアーキテクチャレイヤーです。プリンシパルはサービス層に渡されて認可決定を行うことができますが、そうすると、すべてのサービス層メソッドに追加の引数が導入されます。より洗練されたアプローチは、ThreadLocal を使用してプリンシパルを保持することです。ただし、専用のセキュリティフレームワークを使用するだけで、より経済的に(費用対効果で)なるまで開発時間が長くなる可能性があります。
    4. 認証コードの品質 : Web フレームワークでは、「正しいことをするのが簡単になり、間違ったことをするのが難しくなる」とよく言われます。セキュリティフレームワークは、さまざまな目的のために抽象的な方法で設計されているため、同じです。独自の認証コードを最初から作成しても、フレームワークが提供する「設計チェック」は提供されません。また、社内の認証コードには一般に、広範囲にわたるデプロイ、ピアレビュー、新しいバージョンから生じる改善が欠落しています。

単純なアプリケーションの場合、サーブレット仕様のセキュリティで十分な場合があります。Web コンテナーの移植性、構成要件、制限された Web リクエストセキュリティの柔軟性、および存在しないサービスレイヤーとドメインオブジェクトインスタンスのセキュリティのコンテキスト内で検討すると、開発者が代替ソリューションをよく検討する理由が明らかになります。

どの Java および Spring Framework バージョンが必要ですか?

Spring Security 3.0 と 3.1 には、少なくとも JDK 1.5 が必要であり、最低でも Spring 3.0.3 が必要です。理想的には、問題を回避するために最新のリリースバージョンを使用する必要があります。

Spring Security 2.0.x には、1.4 の最小 JDK バージョンが必要であり、Spring 2.0.x に対してビルドされます。また、Spring 2.5.x を使用するアプリケーションとも互換性があります。

Spring Security を初めて使用します。HTTPS を介した CAS シングルサインオンをサポートし、特定の URL に対して基本認証をローカルで許可し、複数のバックエンドユーザー情報ソース(LDAP および JDBC)に対して認証するアプリケーションを構築する必要があります。見つけたいくつかの構成ファイルをコピーしましたが、機能しません。

何が間違っているためしょうか?

または、代替の複雑なシナリオを置き換えます。…

現実には、アプリケーションを正常に構築する前に、使用する技術を理解する必要があります。セキュリティは複雑です。ログインフォームと Spring Security の名前空間を使用するハードコードされたユーザーを使用して簡単な構成をセットアップするのは、かなり簡単です。バックアップされた JDBC データベースの使用への移行も簡単です。しかし、このような複雑なデプロイシナリオに直行しようとすると、ほぼ間違いなくイライラします。CAS などのシステムをセットアップし、LDAP サーバーを構成し、SSL 証明書を適切にインストールするために必要な学習曲線に大きなジャンプがあります。そのため、一度に 1 つのステップを踏む必要があります。

Spring Security の観点から、最初にするべきことは、Web サイトの「入門」ガイドに従うことです。これにより、一連の手順を実行して、フレームワークがどのように動作するかを理解することができます。慣れていない他の技術を使用している場合は、いくつかの研究を行い、分離して使用できることを確認してから、複雑なシステムで組み合わせてください。

20.4.2 よくある問題

  1. 認証

  2. セッション管理

  3. その他

ログインしようとすると、「不正な資格情報」というエラーメッセージが表示されます。どうしてでしょうか?

これは、認証が失敗したことを意味します。攻撃者がアカウント名またはパスワードを推測するのに役立つ可能性のある詳細を提供しないことをお勧めするため、理由はわかりません。

これはまた、フォーラムでこの質問をした場合、追加情報を提供しない限り回答を得られないことを意味します。他の課題と同様に、デバッグログからの出力を確認し、例外スタックトレースと関連メッセージをメモしてください。デバッガーでコードをステップ実行して、認証が失敗した場所と理由を確認します。アプリケーションの外部で認証設定を実行するテストケースを作成します。多くの場合、失敗の原因は、データベースに保存されているパスワードデータとユーザーが入力したパスワードデータの違いにあります。ハッシュ化されたパスワードを使用している場合は、データベースに保存されている値が、アプリケーションで構成されている PasswordEncoder によって生成された値と正確に同じであることを確認してください。

ログインしようとすると、アプリケーションが「無限ループ」に入ります。

無限ループとログインページへのリダイレクトに関する一般的なユーザーの問題は、誤ってログインページを「保護された」リソースとして構成することによって発生します。セキュリティフィルターチェーンから除外するか、ROLE_ANONYMOUS を必要とするものとしてマークすることにより、構成がログインページへの匿名アクセスを許可することを確認してください。

AccessDecisionManager に AuthenticatedVoter が含まれている場合、属性「IS_AUTHENTICATED_ANONYMOUSLY」を使用できます。これは、標準のネームスペース構成セットアップを使用している場合、自動的に利用可能です。

Spring Security 2.0.1 以降、名前空間ベースの設定を使用している場合、アプリケーションコンテキストのロード時にチェックが行われ、ログインページが保護されているように見える場合は警告メッセージがログに記録されます。

「アクセスが拒否されます(ユーザーは匿名です);」というメッセージで例外が発生します。どうしてでしょうか?

これは、匿名ユーザーが保護されたリソースに初めてアクセスしようとしたときに発生するデバッグレベルのメッセージです。

DEBUG [ExceptionTranslationFilter] - Access is denied (user is anonymous); redirecting to authentication entry point
org.springframework.security.AccessDeniedException: Access is denied
at org.springframework.security.vote.AffirmativeBased.decide(AffirmativeBased.java:68)
at org.springframework.security.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:262)

これは正常なことであり、心配する必要はありません。

アプリケーションからログアウトした後でも、保護されたページが表示されるのはなぜですか?

これの最も一般的な理由は、ブラウザーがページをキャッシュしており、ブラウザーのキャッシュから取得されているコピーが表示されていることです。ブラウザーが実際にリクエストを送信しているかどうかを確認して、これを確認します(サーバーアクセスログ、デバッグログを確認するか、Firefox の「改ざんデータ」などの適切なブラウザーデバッグプラグインを使用します)。これは Spring Security とは関係ありません。適切な Cache-Control レスポンスヘッダーを設定するようにアプリケーションまたはサーバーを構成する必要があります。SSL リクエストはキャッシュされないことに注意してください。

「SecurityContext で認証オブジェクトが見つかりませんでした」というメッセージで例外が発生します。どうしてでしょうか?

これは、匿名ユーザーが保護されたリソースに初めてアクセスしようとしたときに、フィルターチェーン構成に AnonymousAuthenticationFilter がない場合に発生する別のデバッグレベルメッセージです。

DEBUG [ExceptionTranslationFilter] - Authentication exception occurred; redirecting to authentication entry point
org.springframework.security.AuthenticationCredentialsNotFoundException:
                            An Authentication object was not found in the SecurityContext
at org.springframework.security.intercept.AbstractSecurityInterceptor.credentialsNotFound(AbstractSecurityInterceptor.java:342)
at org.springframework.security.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:254)

これは正常なことであり、心配する必要はありません。

LDAP 認証が機能しません。

構成の何が問題になっていますか?

LDAP ディレクトリのアクセス許可では、多くの場合、ユーザーのパスワードを読み取れないことに注意してください。そのため、Spring Security が保存されたパスワードとユーザーが送信したパスワードを比較する「UserDetailsService とは何ですか。必要ですか? 」を使用することはできません。最も一般的なアプローチは、LDAP プロトコル (英語) でサポートされる操作の 1 つである LDAP「バインド」を使用することです。このアプローチでは、Spring Security はユーザーとしてディレクトリへの認証を試みることによりパスワードを検証します。

LDAP 認証の最も一般的な問題は、ディレクトリサーバーのツリー構造と構成に関する知識の不足です。これは企業によって異なるため、自分で調べる必要があります。Spring Security LDAP 構成をアプリケーションに追加する前に、標準の Java LDAP コードを使用して(Spring Security を使用せずに)簡単なテストを作成し、それが最初に機能することを確認することをお勧めします。例: ユーザーを認証するには、次のコードを使用できます。

@Test
public void ldapAuthenticationIsSuccessful() throws Exception {
        Hashtable<String,String> env = new Hashtable<String,String>();
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL, "cn=joe,ou=users,dc=mycompany,dc=com");
        env.put(Context.PROVIDER_URL, "ldap://mycompany.com:389/dc=mycompany,dc=com");
        env.put(Context.SECURITY_CREDENTIALS, "joespassword");
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");

        InitialLdapContext ctx = new InitialLdapContext(env, null);

}

セッション管理

セッション管理の課題は、フォーラムの質問の一般的なソースです。Java Web アプリケーションを開発している場合、サーブレットコンテナーとユーザーのブラウザー間でセッションがどのように維持されるかを理解する必要があります。また、セキュア Cookie と非セキュア Cookie の違いと、HTTP/HTTPS を使用して 2 つの間を切り替えることの意味を理解する必要があります。Spring Security は、セッションの維持またはセッション ID の提供とは関係ありません。これは、サーブレットコンテナーによって完全に処理されます。

Spring Security の同時セッション制御を使用して、ユーザーが一度に複数回ログインするのを防ぎます。

ログイン後に別のブラウザーウィンドウを開いても、再度ログインすることはできません。なぜ複数回ログインできるのですか?

ブラウザーは通常、ブラウザーインスタンスごとに 1 つのセッションを維持します。一度に 2 つの別々のセッションを持つことはできません。別のウィンドウまたはタブで再度ログインすると、同じセッションで再認証するだけです。サーバーは、タブ、ウィンドウ、またはブラウザーインスタンスについて何も知りません。表示されるのは HTTP リクエストだけであり、含まれている JSESSIONIDCookie の値に従って特定のセッションに関連付けます。ユーザーがセッション中に認証を行うと、Spring Security の同時セッション制御は、ユーザーが持っている他の認証済みセッションの数をチェックします。それらが同じセッションですでに認証されている場合、再認証は効果がありません。

Spring Security で認証すると、セッション ID が変わるのはなぜですか?

デフォルト構成では、Spring Security はユーザーが認証されるとセッション ID を変更します。Servlet 3.1 以降のコンテナーを使用している場合、セッション ID は単に変更されます。古いコンテナーを使用している場合、Spring Security は既存のセッションを無効にし、新しいセッションを作成して、セッションデータを新しいセッションに転送します。この方法でセッション識別子を変更すると、「セッション固定」攻撃を防ぐことができます。この詳細については、オンラインおよびリファレンスマニュアルを参照してください。

Tomcat(または他のサーブレットコンテナー)を使用しており、ログインページで HTTPS を有効にし、その後 HTTP に戻りました。

効かない - 認証後、ログインページに戻ります。

これは、セッション Cookie が「セキュア」とマークされている HTTPS で作成されたセッションは、その後 HTTP で使用できないために発生します。ブラウザーは Cookie をサーバーに返送せず、セッションの状態はすべて失われます(セキュリティコンテキスト情報を含む)。セッション Cookie はセキュアとしてマークされないため、最初に HTTP でセッションを開始すると機能します。ただし、Spring Security のセッション固定保護 (英語) は、通常はセキュアフラグを使用して、新しいセッション ID Cookie がユーザーのブラウザーに送り返されるため、これに干渉する可能性があります。これを回避するために、セッション固定保護を無効にすることができますが、新しいサーブレットコンテナーでは、セキュアフラグを使用しないようにセッション Cookie を構成することもできます。HTTP を使用するアプリケーションは中間者攻撃に対して脆弱であるため、HTTP と HTTPS の切り替えは一般的には良いアイデアではないことに注意してください。本当に安全にするために、ユーザーは HTTPS でサイトへのアクセスを開始し、ログアウトするまでサイトの使用を続ける必要があります。HTTP 経由でアクセスしたページから HTTPS リンクをクリックすることは、潜在的に危険です。さらに説得力が必要な場合は、sslstrip (英語) のようなツールをチェックしてください。

HTTP と HTTPS を切り替えていませんが、セッションがまだ失われています

セッションは、セッション Cookie を交換するか、URL に jsessionid パラメーターを追加することで維持されます(JSTL を使用して URL を出力する場合、または URL で HttpServletResponse.encodeUrl を呼び出す場合(リダイレクトの前など)。jsessionid を含めるように URL を書き換えていない場合、セッションは失われます。URL のセッション情報を公開しないため、セキュリティ上の理由から Cookie の使用が推奨されます。

同時セッション制御サポートを使用しようとしていますが、ログアウトしていて許可されたセッションを超えていないと確信しても、再度ログインすることはできません。

web.xml ファイルにリスナーを追加したことを確認してください。セッションが破棄されたときに Spring Security セッションレジストリに通知されるようにすることが不可欠です。これがないと、セッション情報はレジストリから削除されません。

<listener>
        <listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>

Spring Security は、create-session 属性を never に設定することにより、設定していないにもかかわらず、どこかにセッションを作成しています。

これは通常、ユーザーのアプリケーションがどこかでセッションを作成しているが、それを認識していないことを意味します。最も一般的な犯人は JSP です。多くの人は、JSP がデフォルトでセッションを作成することを認識していません。JSP がセッションを作成しないようにするには、ページの上部にディレクティブ <%@ page session="false" %> を追加します。

セッションの作成場所の解決に問題がある場合は、デバッグコードを追加して場所を追跡できます。これを行う 1 つの方法は、javax.servlet.http.HttpSessionListener をアプリケーションに追加し、sessionCreated メソッドで Thread.dumpStack() を呼び出すことです。

POST を実行すると 403 Forbidden が発生する

HTTP 403 Forbidden が HTTP POST に対して返されるが、HTTP GET に対しては機能する場合、課題は CSRF (英語) に関連している可能性があります。CSRF トークンを提供するか、CSRF 保護を無効にします(非推奨)。

RequestDispatcher を使用してリクエストを別の URL に転送していますが、セキュリティ上の制約は適用されていません。

デフォルトでは、フィルターは転送または組み込みに適用されません。セキュリティフィルターを転送やインクルードに実際に適用する場合は、<filter-mapping> の子要素である <dispatcher> 要素を使用して web.xml でこれらを明示的に構成する必要があります。

Spring Security の <global-method-security> 要素をアプリケーションコンテキストに追加しましたが、Spring MVC コントローラー Bean(Struts アクションなど)にセキュリティアノテーションを追加しても効果はないようです。

Spring Web アプリケーションでは、ディスパッチャーサーブレットの Spring MVC Bean を保持するアプリケーションコンテキストは、メインアプリケーションコンテキストから分離されていることがよくあります。多くの場合、myapp-servlet.xml というファイルで定義されます。「myapp」は、web.xml の Spring DispatcherServlet に割り当てられた名前です。アプリケーションは複数の DispatcherServlet を持つことができ、それぞれに独自の分離されたアプリケーションコンテキストがあります。これらの「子」コンテキストの Bean は、アプリケーションの他の部分からは見えません。「親」アプリケーションコンテキストは、web.xml で定義した ContextLoaderListener によってロードされ、すべての子コンテキストに表示されます。通常、この親コンテキストは、<global-method-security> 要素を含むセキュリティ構成を定義する場所です。その結果、これらの Web Bean のメソッドに適用されるセキュリティ制約は、DispatcherServlet コンテキストから Bean を見ることができないため、強制されません。<global-method-security> 宣言を Web コンテキストに移動するか、保護したい Bean をメインアプリケーションコンテキストに移動する必要があります。

一般に、個々の Web コントローラーではなく、サービスレイヤーでメソッドセキュリティを適用することをお勧めします。

確実に認証されたユーザーがいますが、リクエスト中に SecurityContextHolder にアクセスしようとすると、認証が null になります。

ユーザー情報が表示されないのはなぜですか?

URL パターンに一致する <intercept-url> 要素の属性 filters='none' を使用してセキュリティフィルターチェーンからリクエストを除外した場合、SecurityContextHolder はそのリクエストに入力されません。デバッグログをチェックして、リクエストがフィルターチェーンを通過しているかどうかを確認します。(デバッグログを読んでいます。よね? )。

認可 JSP タグは、URL 属性を使用するときにメソッドセキュリティアノテーションを考慮しません。

コントローラーがヘッダーや現在のユーザーなどに依存して呼び出すメソッドを決定できるため、どの URL がどのコントローラーエンドポイントにマッピングされるかをリバースエンジニアリングできないため、<sec:authorize> で url 属性を使用する場合、メソッドセキュリティはリンクを隠しません。

20.4.3 Spring Security アーキテクチャに関する質問

どのパッケージクラス X が含まれているかを知るにはどうすればよいですか

クラスを見つける最良の方法は、Spring Security ソースを IDE にインストールすることです。ディストリビューションには、プロジェクトが分割される各モジュールのソース jar が含まれています。これらをプロジェクトのソースパスに追加すると、Spring Security クラス(Eclipse の Ctrl-Shift-T)に直接移動できます。また、これによりデバッグが容易になり、例外が発生したコードを直接見て、そこで何が起こっているのかを確認することで、例外のトラブルシューティングを行うことができます。

名前空間要素は、従来の Bean 構成にどのようにマッピングされますか?

リファレンスガイドの名前空間の付録に、名前空間によって作成される Bean の一般的な概要があります。blog.springsource.com (英語) には、「Spring Security 名前空間の背後にある」という詳細なブログ記事もあります。詳細を知りたい場合、コードは Spring Security 3.0 ディストリビューション内の spring-security-config モジュールにあります。最初に、標準の Spring Framework リファレンスドキュメントの名前空間解析に関する章を読む必要があります。

「ROLE_」とは何を意味し、なぜロール名にそれが必要なのですか?

Spring Security には、投票者ベースのアーキテクチャがあります。つまり、一連の AccessDecisionVoter によってアクセス決定が行われます。投票者は、セキュリティで保護されたリソース(メソッド呼び出しなど)に指定された「構成属性」に基づいて行動します。このアプローチでは、すべての属性がすべての投票者に関連するわけではなく、投票者は、属性値に基づいて、いつ属性を無視するか(棄権)、いつアクセスを許可または拒否するかを知る必要があります。最も一般的な投票者は RoleVoter であり、これはデフォルトで「ROLE_」プレフィックスを持つ属性を見つけるたびに投票します。これは、属性(「ROLE_USER」など)と、現在のユーザーが割り当てられている機関の名前を簡単に比較します。一致するものが見つかった場合(「ROLE_USER」と呼ばれる機関があります)、アクセスを許可するために投票し、そうでない場合はアクセスを拒否するために投票します。

RoleVoter の rolePrefix プロパティを設定することにより、プレフィックスを変更できます。アプリケーションでロールのみを使用する必要があり、他のカスタム投票者を必要としない場合、プレフィックスを空の文字列に設定できます。その場合、RoleVoter はすべての属性をロールとして扱います。

Spring Security で動作するためにアプリケーションに追加する依存関係を知るにはどうすればよいですか?

これは、使用している機能や開発しているアプリケーションの種類によって異なります。Spring Security 3.0 を使用すると、プロジェクト jar は機能の明確に異なる領域に分割されるため、アプリケーション要件から必要な Spring Security jar を簡単に特定できます。すべてのアプリケーションには spring-security-core jar が必要です。Web アプリケーションを開発している場合は、spring-security-web jar が必要です。セキュリティ名前空間構成を使用している場合は、spring-security-config jar が必要です。LDAP サポートには、spring-security-ldap jar などが必要です。

サードパーティの jar の場合、状況は必ずしもそれほど明白ではありません。良い出発点は、ビルド済みのサンプルアプリケーションの WEB-INF/lib ディレクトリのいずれかからコピーすることです。基本的なアプリケーションの場合は、チュートリアルサンプルから開始できます。組み込みのテストサーバーで LDAP を使用する場合は、出発点として LDAP サンプルを使用します。リファレンスマニュアルには、http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#appendix-dependencies[an 付録も含まれています。各 Spring Security モジュールの第 1 レベルの依存関係と、それらがオプションであるかどうか、および何に必要かに関する情報が記載されています。

maven を使用してプロジェクトをビルドする場合、pom.xml に適切な Spring Security モジュールを依存関係として追加すると、フレームワークに必要なコア jar が自動的にプルされます。Spring Security POM ファイルで「オプション」とマークされているものは、必要に応じて独自の pom.xml ファイルに追加する必要があります。

組み込み ApacheDS LDAP サーバーを実行するには、どのような依存関係が必要ですか?

Maven を使用している場合は、pom の依存関係に以下を追加する必要があります。

<dependency>
        <groupId>org.apache.directory.server</groupId>
        <artifactId>apacheds-core</artifactId>
        <version>1.5.5</version>
        <scope>runtime</scope>
</dependency>
<dependency>
        <groupId>org.apache.directory.server</groupId>
        <artifactId>apacheds-server-jndi</artifactId>
        <version>1.5.5</version>
        <scope>runtime</scope>
</dependency>

他の必要な jar は推移的にプルする必要があります。

UserDetailsService とは何ですか?

UserDetailsService は、ユーザーアカウントに固有のデータを読み込むための DAO インターフェースです。フレームワーク内の他のコンポーネントで使用するためにそのデータをロードする他の機能はありません。ユーザーを認証する責任はありません。ユーザー名 / パスワードの組み合わせを使用したユーザーの認証は、ほとんどの場合、DaoAuthenticationProvider によって実行されます。DaoAuthenticationProvider には UserDetailsService が挿入され、送信された値と比較するためにユーザーのパスワード(およびその他のデータ)を読み込むことができます。LDAP を使用している場合、このアプローチは機能しない可能性があることに注意してください。

認証プロセスをカスタマイズする場合は、AuthenticationProvider を自分で実装する必要があります。Spring Security 認証を Google App Engine に統合する例については、このブログ記事 (英語) を参照してください。

20.4.4 一般的な「Howto」リクエスト

ユーザー名以外の情報でログインする必要があります。

追加のログインフィールド(会社名など)のサポートを追加するにはどうすればよいですか?

この質問は Spring Security フォーラムに繰り返し出てくるため、アーカイブを検索する(または google で検索する)ことで、より多くの情報を見つけることができます。

送信されたログイン情報は、UsernamePasswordAuthenticationFilter のインスタンスによって処理されます。このクラスをカスタマイズして、追加のデータフィールドを処理する必要があります。一つの選択肢は、独自のカスタマイズされた認証トークンクラス (標準的な UsernamePasswordAuthenticationToken ではなく) を使用することであり、もう一つの選択肢は、余分なフィールドをユーザー名 (たとえば、セパレータとして「: 」を使用) と連結し、UsernamePasswordAuthenticationToken の username プロパティに渡すことです。

また、実際の認証プロセスをカスタマイズする必要があります。たとえば、カスタム認証トークンクラスを使用している場合、AuthenticationProvider を記述してそれを処理する(または標準の DaoAuthenticationProvider を継承する)必要があります。フィールドを連結している場合、独自の UserDetailsService を実装して、フィールドを分割し、認証用の適切なユーザーデータをロードできます。

リクエストされた URL のフラグメント値のみが異なる(たとえば、/ foo#bar と /foo#blah? の)異なる intercept-url 制約を適用する方法

フラグメントはブラウザーからサーバーに送信されないため、これを行うことはできません。上記の URL は、サーバーの観点からは同一です。これは GWT ユーザーからのよくある質問です。

UserDetailsService でユーザーの IP アドレス(または他の Web リクエストデータ)にアクセスするにはどうすればよいですか?

インターフェースに提供される情報はユーザー名のみであるため、明らかに(スレッドローカル変数のようなものに頼ることなく)できません。UserDetailsService を実装する代わりに、AuthenticationProvider を直接実装し、提供された Authentication トークンから情報を抽出する必要があります。

標準の Web セットアップでは、Authentication オブジェクトの getDetails() メソッドは WebAuthenticationDetails のインスタンスを返します。追加情報が必要な場合は、使用している認証フィルターにカスタム AuthenticationDetailsSource を挿入できます。<form-login> 要素などで名前空間を使用している場合、この要素を削除し、明示的に設定された UsernamePasswordAuthenticationFilter を指す <custom-filter> 宣言で置き換える必要があります。

UserDetailsService から HttpSession にアクセスするにはどうすればよいですか?

UserDetailsService はサーブレット API を認識しないため、できません。カスタムユーザーデータを保存する場合は、返される UserDetails オブジェクトをカスタマイズする必要があります。これは、スレッドローカル SecurityContextHolder を介して、いつでもアクセスできます。SecurityContextHolder.getContext().getAuthentication().getPrincipal() を呼び出すと、このカスタムオブジェクトが返されます。

セッションに本当にアクセスする必要がある場合は、Web 層をカスタマイズしてアクセスする必要があります。

UserDetailsService でユーザーのパスワードにアクセスするにはどうすればよいですか?

できません(できません)。おそらくその目的を誤解しているでしょう。上記の「UserDetailsService とは何ですか? 」を参照してください。

アプリケーション内でセキュアな URL を動的に定義するにはどうすればよいですか

保護された URL とセキュリティメタデータ属性の間のマッピングを、アプリケーションコンテキストではなくデータベースに保存する方法についてよく尋ねられます。

最初に自問すべきことは、本当にこれを行う必要があるかどうかです。アプリケーションで保護が必要な場合、定義されたポリシーに基づいてセキュリティを徹底的にテストすることも必要です。本番環境に展開する前に、監査と受け入れテストが必要になる場合があります。セキュリティを重視する組織は、構成データベースの 1 行または 2 行を変更することにより、実行時にセキュリティ設定を変更できるようにすることで、勤勉なテストプロセスの利点をすぐに一掃できることに注意する必要があります。これを考慮した場合(おそらくアプリケーション内で複数のセキュリティレイヤーを使用している場合)、Spring Security を使用すると、セキュリティメタデータのソースを完全にカスタマイズできます。必要に応じて完全に動的にすることができます。

メソッドおよび Web セキュリティは、AbstractSecurityInterceptor のサブクラスによって保護されています。AbstractSecurityInterceptor は、特定のメソッドまたはフィルター呼び出しのメタデータを取得する SecurityMetadataSource で構成されています。Web セキュリティの場合、インターセプタークラスは FilterSecurityInterceptor であり、マーカーインターフェース FilterInvocationSecurityMetadataSource を使用します。動作する「保護されたオブジェクト」型は FilterInvocation です。使用されるデフォルトの実装(名前空間 <http> 内およびインターセプターを明示的に構成する場合の両方)は、インメモリマップに URL パターンのリストと「構成属性」(ConfigAttribute のインスタンス)の対応するリストを格納します。

代替ソースからデータをロードするには、明示的に宣言されたセキュリティフィルターチェーン(通常 Spring Security の FilterChainProxy)を使用して、FilterSecurityInterceptor Bean をカスタマイズする必要があります。名前空間は使用できません。その後、FilterInvocationSecurityMetadataSource を実装して、特定の FilterInvocation [17] に必要なデータをロードします。非常に基本的なアウトラインは次のようになります。

public class MyFilterSecurityMetadataSource implements FilterInvocationSecurityMetadataSource {

    public List<ConfigAttribute> getAttributes(Object object) {
        FilterInvocation fi = (FilterInvocation) object;
            String url = fi.getRequestUrl();
            String httpMethod = fi.getRequest().getMethod();
            List<ConfigAttribute> attributes = new ArrayList<ConfigAttribute>();

            // Lookup your database (or other source) using this information and populate the
            // list of attributes

            return attributes;
    }

    public Collection<ConfigAttribute> getAllConfigAttributes() {
        return null;
    }

    public boolean supports(Class<?> clazz) {
        return FilterInvocation.class.isAssignableFrom(clazz);
    }
}

詳細については、DefaultFilterInvocationSecurityMetadataSource のコードを参照してください。

LDAP に対して認証するが、データベースからユーザーロールをロードするにはどうすればよいですか?

LdapAuthenticationProvider Bean(Spring Security で通常の LDAP 認証を処理する)は、認証を実行するものと、それぞれ LdapAuthenticator および LdapAuthoritiesPopulator と呼ばれるユーザー権限をロードするものの 2 つの別個の戦略インターフェースで構成されます。DefaultLdapAuthoritiesPopulator は、LDAP ディレクトリからユーザー権限をロードし、これらを取得する方法を指定できるさまざまな構成パラメーターを持っています。

代わりに JDBC を使用するには、スキーマに適した SQL を使用して、自分でインターフェースを実装できます。

public class MyAuthoritiesPopulator implements LdapAuthoritiesPopulator {
    @Autowired
    JdbcTemplate template;

    List<GrantedAuthority> getGrantedAuthorities(DirContextOperations userData, String username) {
        List<GrantedAuthority> = template.query("select role from roles where username = ?",
                                                                                                new String[] {username},
                                                                                                new RowMapper<GrantedAuthority>() {
            /**
             *  We're assuming here that you're using the standard convention of using the role
             *  prefix "ROLE_" to mark attributes which are supported by Spring Security's RoleVoter.
             */
            public GrantedAuthority mapRow(ResultSet rs, int rowNum) throws SQLException {
                return new SimpleGrantedAuthority("ROLE_" + rs.getString(1);
            }
        }
    }
}

次に、この型の Bean をアプリケーションコンテキストに追加し、LdapAuthenticationProvider に挿入します。これについては、リファレンスマニュアルの LDAP の章の明示的な Spring Bean を使用した LDAP の設定に関するセクションで説明されています。この場合、構成に名前空間を使用できないことに注意してください。関連するクラスとインターフェースについては、Javadoc も参照してください。

名前空間によって作成された Bean のプロパティを変更したいのですが、スキーマにはそれをサポートするものが何もありません。

名前空間の使用を放棄する前に何ができますか?

名前空間の機能は意図的に制限されているため、プレーン Bean で実行できるすべてをカバーしているわけではありません。Bean を変更したり、別の依存関係を挿入したりするなど、簡単なことをしたい場合は、BeanPostProcessor を構成に追加することでこれを行うことができます。詳細については、Spring リファレンスマニュアル (英語) を参照してください。これを行うには、どの Bean が作成されているかについて少し知る必要があります。したがって、ネームスペースが Spring Beanどのようにマッピングされるかについての上記の質問のブログ記事も読む必要があります。

通常、必要な機能を BeanPostProcessor の postProcessBeforeInitialization メソッドに追加します。UsernamePasswordAuthenticationFilter で使用される AuthenticationDetailsSource (form-login 要素で作成)をカスタマイズするとします。リクエストから CUSTOM_HEADER と呼ばれる特定のヘッダーを抽出し、ユーザーの認証中にそれを使用する必要があります。プロセッサークラスは次のようになります。

public class BeanPostProcessor implements BeanPostProcessor {

        public Object postProcessAfterInitialization(Object bean, String name) {
                if (bean instanceof UsernamePasswordAuthenticationFilter) {
                        System.out.println("********* Post-processing " + name);
                        ((UsernamePasswordAuthenticationFilter)bean).setAuthenticationDetailsSource(
                                        new AuthenticationDetailsSource() {
                                                public Object buildDetails(Object context) {
                                                        return ((HttpServletRequest)context).getHeader("CUSTOM_HEADER");
                                                }
                                        });
                }
                return bean;
        }

        public Object postProcessBeforeInitialization(Object bean, String name) {
                return bean;
        }
}

次に、この Bean をアプリケーションコンテキストに登録します。Spring は、アプリケーションコンテキストで定義された Bean で自動的に呼び出します。



[14]web.xml からマッピングをセットアップする方法については、入門の章を参照してください

[15] この機能は、実際には便宜上提供されたものであり、本番用ではありません(ビューテクノロジーが選択され、カスタマイズされたログインページのレンダリングに使用できます)。クラス DefaultLoginPageGeneratingFilter は、ログインページのレンダリングを担当し、必要に応じて、通常のフォームログインおよび / または OpenID の両方にログインフォームを提供します。

[16] これは、トークンがサーバー側に保存される PersistentTokenBasedRememberMeServices の使用には影響しません。

[17]FilterInvocation オブジェクトには HttpServletRequest が含まれているため、返された属性のリストに含まれるものに基づいて決定を行うための URL またはその他の関連情報を取得できます。

現行バージョンへ切り替える