xDev Asia

SAML 2.0 クライアント、SAML バインディング (POST、リダイレクト、アーティファクト)、アサーション構成、XML 署名と暗号化、エンティティ記述子のインポート、IDP 開始ログインを作成および構成します。 OIDC および SAML のプロトコルマッパー、軽量アクセストークン、ペアワイズサブジェクト識別子。

基本から上級までの Keycloak

パート 2: SSO プロトコル - OpenID Connect と SAML

xdev.asia

1. KeycloakのSAML 2.0の概要

SAML 2.0 (Security Assertion Markup Language) は、企業内で広く使用されている XML ベースの認証プロトコルで、特に従来のシステム、SaaS アプリケーション (Salesforce、ServiceNow、AWS)、または政府機関と統合する場合に使用されています。

SAML 2.0 と OpenID Connect の比較

特性	SAML 2.0	OpenID コネクト
形式	XML	JSON (JWT)
輸送	HTTP リダイレクト、POST、アーティファクト	HTTP REST
トークン	SAML アサーション (XML)	JWT
サイズ	より大きい (XML 冗長)	コンパクト (JSON)
モバイルサポート	不十分 (XML 解析が重い)	良い (JSON ネイティブ)
主な使用例	エンタープライズ SSO、レガシーシステム	最新の Web/モバイルアプリ
複雑	高い	より低い
ログアウト	SLO (シングルログアウト)	RP 開始、バックチャネル、フロントチャネル

SAML をいつ使用するか?

SAML を必要とする SaaS アプリケーション (Salesforce、Google Workspace、AWS) との統合
SAML のみをサポートする IdP または SP にバインドする
政府機関の基準への準拠を要求する
ADFS システム、Shibboleth からの移行

SAML 用語

用語	説明する	OIDCと同等
アイデンティティプロバイダー (IdP)	ユーザー認証側（Keycloak）	OpenID プロバイダー (OP)
サービスプロバイダー（SP）	認証要求元（アプリケーション）	依拠当事者 (RP)
アサーション	XML ドキュメントには認証情報が含まれています	トークンID
認可リクエスト	SP → IdP から認証を要求する	認可リクエスト
ACS URL	アサーションコンシューマサービス URL	リダイレクトURI
エンティティID	SP/IdPの一意の識別子	クライアントID / 発行者
メタデータ	エンドポイント、証明書を記述する XML	よく知られた構成
名前ID	アサーション内のユーザー識別子	サブクレーム
属性ステートメント	アサーション内のユーザー属性	JWT のクレーム

2. SAML 2.0 クライアントの作成

2.1 管理コンソール経由で作成する

アクセス管理コンソール→ レルムを選択 →クライアント → クライアントの作成
一般設定:
- クライアントの種類: SAML
- クライアントID: URL ベースのエンティティ ID などhttps://myapp.example.com/saml/metadata
- 名前: 私の SAML アプリケーション
クリック次そして保存

2.2 エンティティ記述子（メタデータ）からのインポート

SAML クライアントを作成する最速の方法 - サービスプロバイダーから XML メタデータをインポートします。

アクセスクライアント → インポートクライアント
XML メタデータファイルをアップロードするか、URL メタデータを貼り付けます
Keycloakは、エンティティID、ACS URL、SLO URL、証明書、バインディングを自動的に入力します。

サービスプロバイダーの XML メタデータの例:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://myapp.example.com/saml/metadata">
  <md:SPSSODescriptor
      AuthnRequestsSigned="true"
      WantAssertionsSigned="true"
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
&lt;md:KeyDescriptor use="signing"&gt;
  &lt;ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
    &lt;ds:X509Data&gt;
      &lt;ds:X509Certificate&gt;MIICzDCCAbSg...&lt;/ds:X509Certificate&gt;
    &lt;/ds:X509Data&gt;
  &lt;/ds:KeyInfo&gt;
&lt;/md:KeyDescriptor&gt;

&lt;md:KeyDescriptor use="encryption"&gt;
  &lt;ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
    &lt;ds:X509Data&gt;
      &lt;ds:X509Certificate&gt;MIICzDCCAbSg...&lt;/ds:X509Certificate&gt;
    &lt;/ds:X509Data&gt;
  &lt;/ds:KeyInfo&gt;
&lt;/md:KeyDescriptor&gt;

&lt;md:SingleLogoutService
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://myapp.example.com/saml/slo"/&gt;

&lt;md:NameIDFormat&gt;
  urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
&lt;/md:NameIDFormat&gt;

&lt;md:AssertionConsumerService
    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://myapp.example.com/saml/acs"
    index="0"
    isDefault="true"/&gt;

</md:SPSSODescriptor>
</md:EntityDescriptor>

2.3 Keycloak IdP メタデータの取得

サービスプロバイダーには、構成のために Keycloak メタデータ (IdP) が必要です。メタデータ URL:

GET https://<keycloak-host>/realms/<realm-name>/protocol/saml/descriptor

メタデータには、エンティティ ID、SSO エンドポイント、SLO エンドポイント、署名/暗号化証明書が含まれます。

3. SAML クライアント設定の詳細

3.1 設定タブ

設定	説明する	推奨値
クライアントID（エンティティID）	SAML エンティティ ID — SP の一意の識別子	URL形式:`https://app.example.com/saml`
名前	表示名	アプリケーション名
クライアントの署名が必要です	SP は AuthorizationRequest に署名する必要があります	ON（本番）
POSTバインディングを強制する	応答に対する必須の POST バインディング	の上
フロントチャネルログアウト	ブラウザリダイレクトによるログアウト	の上
強制名 ID 形式	特定の名前 ID 形式が必要です	リクエストに応じて
名前IDの形式	NameIDの形式	電子メールまたは永続的な
IncludeAuthnStatement	アサーションに AuthnStatement を含める	の上
書類に署名する	SAML 応答全体に署名する	の上
アサーションに署名する	応答内のアサーションに署名する	オン（推奨）

3.2 SAML バインディング

SAML は複数のバインディングをサポートしています。SAML メッセージが SP と IdP 間で転送される方法:

バインディング	説明する	ユースケース
HTTP-POST	HTML フォーム自動送信経由で送信されたメッセージ	アサーションのデフォルト (大)
HTTP リダイレクト	URL クエリパラメータを介して送信されるメッセージ	AuthorizationRequest (小)
アーチファクト	アーティファクト参照のみを送信し、SP はバックチャネル経由でアサーションを取得します	高セキュリティ、大規模なアサーション

クライアント設定でバインドを構成します。

設定	説明する
マスターSAML処理URL	すべての SAML バインディングの汎用 URL
アサーションコンシューマサービス POST バインディング URL	POST バインディング用の ACS URL
アサーションコンシューマサービスリダイレクトバインディング URL	リダイレクトバインディング用の ACS URL
アサーションコンシューマサービスアーティファクトバインディング URL	アーティファクトバインディング用の ACS URL
ログアウトサービス POST バインディング URL	POST バインディングの SLO URL
ログアウトサービスリダイレクトバインドURL	リダイレクトバインディングの SLO URL
ログアウトサービスアーティファクトバインディング URL	アーティファクトバインディングの SLO URL

# Ví dụ cấu hình bindings
Master SAML Processing URL: https://myapp.example.com/saml
Assertion Consumer Service POST Binding URL: https://myapp.example.com/saml/acs
Logout Service POST Binding URL: https://myapp.example.com/saml/slo

アーティファクトバインディングの詳細:

アーティファクトバインディングは POST/リダイレクトとは異なります。ブラウザ経由でアサーション全体を送信するのではなく、Keycloak は 1 つのアサーションのみを送信します。アーチファクト(参照ID)。その後、SP は Keycloak を直接 (バックチャネル) 呼び出して、実際のアサーションを取得します。

┌──────────┐     ┌──────────┐     ┌──────────┐
│  Browser │     │    SP    │     │ Keycloak │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     │                │                │
     │  1. Login      │                │
     │───────────────>│                │
     │  2. AuthnRequest               │
     │<──────────────────────────────>│
     │  3. Authentication              │
     │<──────────────────────────────>│
     │  4. Artifact (POST/Redirect)   │
     │<──────────────────────────────│
     │───────────────>│                │
     │                │ 5. ArtifactResolve (backchannel SOAP)
     │                │───────────────>│
     │                │ 6. ArtifactResponse (assertion)
     │                │<──────────────│
     │  7. Authenticated               │
     │<───────────────│                │

アーティファクトバインディングは、アサーションがブラウザを通過しないため、より安全です。アサーションに機密データが含まれている場合に役立ちます。

3.3 XML署名と暗号化

署名構成:

設定	説明する
署名アルゴリズム	XML署名アルゴリズム: RSA_SHA256 (推奨)、RSA_SHA512、DSA_SHA1
SAML署名キー名	署名内のキー名: KEY_ID、CERT_SUBJECT、NONE
正規化方法	XML 正規化: 独占 (推奨)

暗号化構成:

オンにするアサーションの暗号化アサーションを暗号化する - 対応する秘密キーを持つ SP のみが復号化できます。

SP をアップロードする暗号化証明書タブ内キー
暗号化アルゴリズム: AES128、AES256 (推奨)

# Keycloak sẽ mã hóa assertion bằng SP's public key
# Flow: Sign assertion → Encrypt signed assertion → Send to SP
# SP: Decrypt assertion → Verify signature → Extract user info

3.4 タブキー

SAML クライアントの証明書を管理します。

署名キー: SP が AuthnRequest に署名するために使用する証明書 — Keycloak が検証するために使用
暗号化キー: Keycloak がアサーションの暗号化に使用する証明書 — SP は秘密鍵を使用して復号化します

PEM、JKS、または PKCS12 ファイルから証明書をインポートします。

# Generate self-signed certificate cho SP
openssl req -x509 -newkey rsa:2048 \
  -keyout sp-private.pem -out sp-certificate.pem \
  -days 365 -nodes \
  -subj "/CN=myapp.example.com"
Import sp-certificate.pem vào Keycloak client Keys tab

4. SAML アサーションの構成

4.1 名前IDの形式

名前IDは、Keycloakがアサーションでユーザー識別子を送信する方法を決定します。

形式	説明する	ユースケース
`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`	電子メールアドレス	最も人気のある
`urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`	各SPの一意の永続ID	メールを公開したくない
`urn:oasis:names:tc:SAML:2.0:nameid-format:transient`	一時ID、セッションごとに変更	プライバシーに配慮した
`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`	ユーザー名またはKeycloakユーザーID	フレキシブル

4.2 アサーションの存続期間

レルム設定で構成する →トークンタブ:

アサーションの存続期間: 有効なアサーション時間 (デフォルトは 5 分、短くすることをお勧めします)
以前はありませんでした: アサーションはこの時間より前は有効ではありません (クロックスキュー許容値)

4.3 SAML アサーションの例

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_abc123" IssueInstant="2026-03-30T10:00:00Z" Version="2.0">
  <saml:Issuer>http://localhost:8080/realms/my-company</saml:Issuer>
<!-- Subject — user identity -->
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
[email protected]
</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
NotOnOrAfter="2026-03-30T10:05:00Z"
Recipient="https://myapp.example.com/saml/acs"/>
</saml:SubjectConfirmation>
</saml:Subject>
<!-- Conditions — khi nào assertion hợp lệ -->
<saml:Conditions NotBefore="2026-03-30T10:00:00Z" NotOnOrAfter="2026-03-30T10:05:00Z">
<saml:AudienceRestriction>
<saml:Audience>https://myapp.example.com/saml/metadata&lt;/saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<!-- AuthnStatement — thông tin xác thực -->
<saml:AuthnStatement AuthnInstant="2026-03-30T10:00:00Z"
SessionIndex="session_abc123">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<!-- AttributeStatement — user attributes -->
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>[email protected]</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="firstName">
<saml:AttributeValue>John</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="Role">
<saml:AttributeValue>admin</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>

通常の流れ（SP-Initiated）では、ユーザーがSPにアクセス→SPがIdPにリダイレクト→IdPが認証→SPにリダイレクトとなります。とIDP によって開始されるログインの場合、ユーザーは最初に SP を経由せずに IdP (Keycloak) から開始します。

IDP によるログインの構成

SAMLクライアント→タブを開きます高度な
探すIDP によって開始される SSO URL 名: URL 名を入力します。例:私のアプリ
IDP-Initiated Login への URL は次のようになります。

https://<keycloak-host>/realms/<realm>/protocol/saml/clients/my-app

セキュリティ上の注意:IDP 開始ログインには CSRF リスクがあります - アサーションは利用できません返信先属性。 SP によって必要な場合にのみ使用してください (一部の SaaS アプリは IDP-Initiated のみをサポートします)。

IDP によって開始される設定

設定	説明する
IDP によって開始される SSO URL 名	IDP-Initiated Login の末尾の URL
IDP によって開始された SSO リレー状態	SP に送信されるデフォルトの RelayState
アサーションコンシューマサービス POST バインディング URL	URL SP がアサーションを受信する

6. プロトコルマッパー

プロトコルマッパーが決定するトークン/アサーションに含まれる情報。ユーザー属性、ロール、メタデータをクレーム (OIDC) または属性 (SAML) に変換します。

6.1 基本概念

プロトコルマッパーは 2 つのレベルで追加できます。

クライアントレベル: マッパーは特にそのクライアントに適用されます (クライアント → クライアントスコープ → 専用スコープ)
クライアントスコープレベル: マッパーはそのスコープを使用するすべてのクライアントに適用されます

各マッパーには共通の構成があります。

設定	説明する
名前	マッパー名（管理に使用）
マッパータイプ	マッパータイプ (ユーザー属性、ハードコードされたクレームなど)
IDトークンに追加	IDトークンの追加(OIDC)
アクセストークンに追加	アクセストークン(OIDC)の追加
ユーザー情報に追加	UserInfo 応答の追加 (OIDC)
トークンの紹介に追加	トークンイントロスペクション応答の追加
軽量アクセストークンに追加	ライトウェイトアクセストークンを追加しました

6.2 OIDC プロトコルマッパー

ユーザー属性マッパー— ユーザー属性をトークン要求にマップします。

Mapper Type: User Attribute
Name: department-mapper
User Attribute: department         # attribute name trong User Profile
Token Claim Name: department       # claim name trong JWT
Claim JSON Type: String            # String, long, int, boolean, JSON
Add to ID token: ON
Add to access token: ON
Add to userinfo: ON
Multivalued: OFF

JWT での結果:

{
  "sub": "user-id",
  "email": "[email protected]",
  "department": "Engineering",
  ...
}

ユーザープロパティマッパー— 組み込みユーザープロパティ (ユーザー名、電子メール、名、姓) をマップします。

Mapper Type: User Property
Name: full-name-mapper
Property: firstName
Token Claim Name: given_name
Claim JSON Type: String

ユーザーセッションノートマッパー— セッションデータをトークンにマッピングします。

Mapper Type: User Session Note
Name: client-ip-mapper
User Session Note: clientAddress    # hoặc clientHost, identity_provider, etc.
Token Claim Name: client_ip
Claim JSON Type: String
Add to access token: ON

セッションノートが利用可能:クライアントアドレス, クライアントホスト, アイデンティティプロバイダー, アイデンティティプロバイダアイデンティティ.

ハードコードされたクレームマッパー— 固定値を持つクレームを追加します。

Mapper Type: Hardcoded claim
Name: environment-mapper
Token Claim Name: env
Claim value: production
Claim JSON Type: String
Add to access token: ON

グループメンバーシップマッパー— ユーザーのグループリストをトークンに追加します。

Mapper Type: Group Membership
Name: groups-mapper
Token Claim Name: groups
Full group path: ON                 # /parent/child hoặc chỉ child
Add to ID token: ON
Add to access token: ON

結果：

{
  "groups": ["/Engineering", "/Engineering/Backend"]
}

オーディエンスマッパー— アクセストークンに対象者を追加します。

Mapper Type: Audience
Name: api-audience
Included Client Audience: my-api-service   # Client ID của resource server
Add to access token: ON

結果：

{
  "aud": ["my-api-service", "account"]
}

スクリプトマッパー— JavaScript を使用したカスタムロジック:

Mapper Type: Script Mapper
Name: custom-role-mapper
Script:
  // Combine realm roles và client roles thành flat list
  var roles = [];
// Realm roles
var realmRoles = user.getRealmRoleMappingsStream();
realmRoles.forEach(function(role) {
roles.push(role.getName());
});
// Client roles cho client cụ thể
var client = keycloakSession.clients()
.getClientByClientId(realm, 'my-app');
if (client) {
var clientRoles = user.getClientRoleMappingsStream(client);
clientRoles.forEach(function(role) {
roles.push('client:' + role.getName());
});
}
exports = Java.to(roles, "java.lang.String[]");
Token Claim Name: all_roles
Claim JSON Type: JSON
Multivalued: ON

注記: スクリプトマッパーは Nashorn JavaScript エンジンを使用します。 Keycloak 24以降では、スクリプトマッパーをインラインスクリプトではなくカスタムJARプロバイダーとしてデプロイする必要があります。見るデプロイスクリプトKeycloakのドキュメントに記載されています。

6.3 SAML プロトコルマッパー

SAML マッパーは OIDC に似ていますが、出力は JWT クレームではなく SAML 属性です。

ユーザー属性マッパー (SAML):

Mapper Type: User Attribute
Name: department-saml
User Attribute: department
Friendly Name: Department
SAML Attribute Name: urn:oid:2.16.840.1.113730.3.1.241  # hoặc friendly name
SAML Attribute NameFormat: URI Reference                  # URI, Basic, Unspecified

ロールリストマッパー (SAML):

Mapper Type: Role list
Name: role-list
Role attribute name: Role
Friendly Name: Roles
SAML Attribute NameFormat: Basic
Single Role Attribute: ON    # Tất cả roles trong 1 attribute (khuyến nghị)
                              # OFF = mỗi role 1 attribute riêng

ハードコードされた属性マッパー (SAML):

Mapper Type: Hardcoded attribute
Name: tenant-id
SAML Attribute Name: tenant_id
SAML Attribute Value: my-company
Friendly Name: Tenant ID
SAML Attribute NameFormat: Basic

SAML 属性名の形式:

形式	説明する	例えば
基本	シンプルな名前	`電子メール`, `ファーストネーム`
URI リファレンス	OID 形式、標準	`urn:oid:0.9.2342.19200300.100.1.3`
不特定	指定されていない形式	オプション

7. 軽量アクセストークン

デフォルトでは、Keycloakアクセストークンには多くのクレーム（realm_access、resource_access、email、name、preferred_usernameなど）が含まれています。 Lightweight Access Token は、必須のクレームのみを保持することでトークンサイズを削減します。

7.1 ライトウェイトアクセストークンが必要なのはなぜですか?

帯域幅を減らす: トークンが小さい = HTTP ヘッダー経由でより速く送信されます
機密情報を減らす: アクセストークンは多くのサービスに送信されることが多いため、多すぎる PII を含めるべきではありません
セキュリティの向上: リソースサーバーはトークンイントロスペクションを使用して、必要に応じて完全なクレームを取得します

7.2 Lightweight アクセストークンの構成

デフォルトでは、プロトコルマッパーには次のオプションがあります。軽量アクセストークンに追加。使用するには:

マッパーごとにオフにしますアクセストークンに追加軽量トークンでは必要のないクレーム内
クライアントポリシー (次の記事を参照) を使用して、特定のクライアントに軽量トークンを適用する
リソースサーバーはトークンイントロスペクションエンドポイントを呼び出して完全なクレームを取得します。

# Token Introspection — lấy full claims
POST /realms/my-company/protocol/openid-connect/token/introspect
Content-Type: application/x-www-form-urlencoded

token=ACCESS_TOKEN&
client_id=my-resource-server&
client_secret=CLIENT_SECRET

# Response chứa full claims
{
  "active": true,
  "sub": "user-id",
  "email": "[email protected]",
  "realm_access": { "roles": ["admin", "user"] },
  "resource_access": { ... },
  ...
}

8. ペアごとの被験者識別子

デフォルトでは、Keycloakは次を使用します公開サブジェクト識別子- 価値サブクレームはすべてのクライアントに対して同じです。これにより、クライアントはサービス間でユーザーを関連付けることができます。

ペアごとのサブジェクト識別子作成するサブクライアントごとに異なる - サービス間のユーザー追跡を防ぎます。

8.1 ペアワイズ識別子の構成

プロトコルマッパータイプの追加ペアごとのサブジェクト識別子クライアントまたはクライアントスコープに
構成：

Mapper Type: Pairwise subject identifier
Name: pairwise-sub
Salt: random-salt-value-keep-secret   # Salt dùng để hash, PHẢI giữ bí mật
Pairwise Subject Identifier Algorithm: SHA-256
Sector Identifier URI: (tùy chọn)     # Nhóm clients share cùng sub

結果：

# Client A nhận sub:
{ "sub": "hashed-value-for-client-a" }
Client B nhận sub khác:
{ "sub": "hashed-value-for-client-b" }
Cùng 1 user nhưng sub khác nhau → không thể correlate

セクター識別子 URI:

クライアントのグループで共有したい場合サブ(例: 同じサービスの Web アプリとモバイルアプリ)、使用しますセクター識別子 URI。この URI は、同じセクター内のクライアントのリダイレクト URI を含む JSON 配列を指します。

# https://myservice.example.com/sector-identifier.json
["https://webapp.example.com/callback", "myapp://callback"]

9. SAML と Spring Boot を統合する

使用spring-security-saml2-サービスプロバイダーSAML SP を統合するには:

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-saml2-service-provider</artifactId>
</dependency>

# application.yml
spring:
  security:
    saml2:
      relyingparty:
        registration:
          keycloak:
            entity-id: https://myapp.example.com/saml/metadata
            signing:
              credentials:
                - private-key-location: classpath:credentials/sp-private.pem
                  certificate-location: classpath:credentials/sp-certificate.pem
            assertingparty:
              metadata-uri: http://localhost:8080/realms/my-company/protocol/saml/descriptor

// SecurityConfig.java
@Configuration
@EnableWebSecurity
public class SamlSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            )
            .saml2Login(saml2 -> saml2
                .loginPage("/saml2/authenticate/keycloak")
            )
            .saml2Logout(Customizer.withDefaults());
        return http.build();
    }
}

10. 練習問題

ラボ 1: SAML クライアントを作成してアサーションをテストする

エンティティ ID を使用して SAML クライアントを作成するhttps://localhost:8443/saml
ACS URL、署名ドキュメント、署名アサーション = ON を設定します。
使用samltool.comまたは SAML 応答をキャプチャするための SAML-tracer ブラウザ拡張機能
SAML アサーションの分析: NameID、AttributeStatement、条件、署名

ラボ 2: OIDC のプロトコルマッパー

ユーザー属性の作成従業員IDユーザープロフィール内
ユーザー属性マッパーを作成します。従業員ID→ トークンの請求emp_id
グループメンバーシップマッパーの作成: グループ → トークン要求グループ。グループ
ハードコードされたクレームを作成します。環境 = ステージング。ステージング
テスト: トークンを取得し、クレームを検証します。jwt.io

ラボ 3: SAML のプロトコルマッパー

SAML ユーザー属性マッパーの作成部門
ロールリストマッパーを作成する単一の役割の属性= オン
名前 ID 形式 = emailAddress の構成
SAML レスポンスをキャプチャし、AttributeStatement を検証する

ラボ 4: ペアごとの被験者識別子

2 つの OIDC クライアントを作成します。アプリ-aそしてアプリ-b
同じソルトを使用して両方のクライアントにペアワイズサブジェクト識別子マッパーを追加する
両方のクライアントに同じユーザーでログインします
値を比較するサブアクセストークン内 — 異なるものである必要があります
2 つのクライアントが共有するセクター識別子 URI を構成するサブ

レッスン 7: SAML クライアントとプロトコルマッパー

1. KeycloakのSAML 2.0の概要

SAML 2.0 と OpenID Connect の比較

SAML 用語

2. SAML 2.0 クライアントの作成

2.1 管理コンソール経由で作成する

2.2 エンティティ記述子（メタデータ）からのインポート

2.3 Keycloak IdP メタデータの取得

3. SAML クライアント設定の詳細

3.1 設定タブ

3.2 SAML バインディング

3.3 XML署名と暗号化

3.4 タブキー

`Import sp-certificate.pem vào Keycloak client Keys tab`

4. SAML アサーションの構成

4.1 名前IDの形式

4.2 アサーションの存続期間

4.3 SAML アサーションの例

IDP によるログインの構成

IDP によって開始される設定

6. プロトコルマッパー

6.1 基本概念

6.2 OIDC プロトコルマッパー

6.3 SAML プロトコルマッパー

7. 軽量アクセストークン

7.1 ライトウェイトアクセストークンが必要なのはなぜですか?

7.2 Lightweight アクセストークンの構成

8. ペアごとの被験者識別子

8.1 ペアワイズ識別子の構成

Client B nhận sub khác:

`Cùng 1 user nhưng sub khác nhau → không thể correlate`

9. SAML と Spring Boot を統合する

10. 練習問題

ラボ 1: SAML クライアントを作成してアサーションをテストする

ラボ 2: OIDC のプロトコルマッパー

ラボ 3: SAML のプロトコルマッパー

ラボ 4: ペアごとの被験者識別子

レッスン 7: SAML クライアントとプロトコル マッパー

1. KeycloakのSAML 2.0の概要

SAML 2.0 と OpenID Connect の比較

SAML 用語

2. SAML 2.0 クライアントの作成

2.1 管理コンソール経由で作成する

2.2 エンティティ記述子（メタデータ）からのインポート

2.3 Keycloak IdP メタデータの取得

3. SAML クライアント設定の詳細

3.1 設定タブ

3.2 SAML バインディング

3.3 XML署名と暗号化

3.4 タブキー

Import sp-certificate.pem vào Keycloak client Keys tab

4. SAML アサーションの構成

4.1 名前IDの形式

4.2 アサーションの存続期間

4.3 SAML アサーションの例

5. IDP によるログイン (一方的な応答)

IDP によるログインの構成

IDP によって開始される設定

6. プロトコル マッパー

6.1 基本概念

6.2 OIDC プロトコル マッパー

6.3 SAML プロトコル マッパー

7. 軽量アクセストークン

7.1 ライトウェイト アクセス トークンが必要なのはなぜですか?

7.2 Lightweight アクセス トークンの構成

8. ペアごとの被験者識別子

8.1 ペアワイズ識別子の構成

Client B nhận sub khác:

Cùng 1 user nhưng sub khác nhau → không thể correlate

9. SAML と Spring Boot を統合する

10. 練習問題

ラボ 1: SAML クライアントを作成してアサーションをテストする

ラボ 2: OIDC のプロトコル マッパー

ラボ 3: SAML のプロトコル マッパー

ラボ 4: ペアごとの被験者識別子

レッスン 7: SAML クライアントとプロトコルマッパー

`Import sp-certificate.pem vào Keycloak client Keys tab`

6. プロトコルマッパー

6.2 OIDC プロトコルマッパー

6.3 SAML プロトコルマッパー

7.1 ライトウェイトアクセストークンが必要なのはなぜですか?

7.2 Lightweight アクセストークンの構成

`Cùng 1 user nhưng sub khác nhau → không thể correlate`

ラボ 2: OIDC のプロトコルマッパー

ラボ 3: SAML のプロトコルマッパー