SAML
SAML ベースの ID プロバイダーを使用している場合は、シングル・サインオン (SSO) エクスペリエンスを開始するように App ID を構成できます。 このタイプのフローでは、 App ID がサービス・プロバイダーとして機能し、月間アクティブ・ユーザー(MAU)に対してセキュリティ・トークンを提供する。
SAML についての説明
Security Assertion Markup Language (SAML) は、ID を表明するプロバイダーと ID 情報を取り込むプロバイダーの間で、認証データと許可データの交換に使用するオープン・スタンダードです。 SAML 2.0 はXMLをベースとしており、認証と認可の標準のための確立されたフレームワークである。
SAML プロトコルは、App ID (サービス・プロバイダー) と ID プロバイダーの間のブリッジを提供します。 ID プロバイダーは、ユーザーを認証すると、そのユーザーに関する情報 (認証方法、関連付けられている属性、許可パラメーターなど) を含む SAML トークンを作成します。 次の表にある例を確認してください。
情報のタイプ | 例 |
---|---|
認証 | ユーザーの認証にパスワードが使用されたのか、MFA が使用されたのか、それとも別の方法が使用されたのか。 |
属性 | ユーザーの所属グループや何らかの設定などの属性。 |
権限の決定 | ユーザーには、他のユーザーと比べて多くの権限が付与されることも、少ない権限が付与されることもある。 |
フローの概要
ユーザーの認証に SAML フレームワークを使用する場合でも、アプリケーションとのセキュリティー・トークンの交換には、App ID は、より新しい OIDC プロトコルを使用します。 次の図を参照して、情報の詳しいフローを確認してください。
- ユーザーはアプリケーション上のログインページまたは制限されたリソースにアクセスし、 App ID SDKまたはAPIのいずれかを介して App ID
/authorization
エンドポイントへのリクエストを開始する。 ユーザーが許可されていない場合、認証フローは App ID へのリダイレクトから始まります。 - App ID が SAML 認証要求 (
AuthNRequest
) を生成し、ブラウザーはユーザーを SAML ID プロバイダーに自動的にリダイレクトします。 - ID プロバイダーが SAML 要求を解析し、ユーザーを認証し、そのユーザーのアサーションを含む SAML 応答を生成します。
- ID プロバイダーが、SAML 応答と一緒にユーザーと応答を App ID にリダイレクトします。
- 認証が成功した場合、App ID は、ユーザーの許可と認証を表すアクセス・トークンと識別トークンを作成し、それらをアプリに返します。 認証が失敗した場合、App ID は ID プロバイダーのエラー・コードをアプリに返します。
- アプリまたは保護リソースへのアクセスがユーザーに許可されます。
SSO によるフローの変化
SSO のワークフローも似ています。 説明したワークフローとの違いは、前のセクションのステップ 3 のみです。 SSO を有効にすると、ユーザーに認証を求める前に、ID プロバイダーが、ユーザーに確立済みの認証セッションが既にあるかどうかを検査します。 ある場合は、ユーザーに認証を求めることなく、通常どおりのフローが続けられます。 SSO セッションがない場合は、ユーザーをログイン・ページにリダイレクトします。 App ID の要求に定義されている認証要件と、SSO を確立するために
ID プロバイダーで使用している要件を、ID プロバイダーが対応付けられない場合も、ユーザーはリダイレクトされます。 例えば、ID プロバイダーが生体認証を使用してユーザーの SSO セッションを確立する場合は、App ID のデフォルトの認証を変更する必要があります。 デフォルトでは、App ID は、HTTPS を介してパスワードでユーザーが認証されること (urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
)
を予期します。
アサーションについて
SAML アサーションが App ID に返されると、サービスはユーザー ID を統合し、該当するトークンを生成します。 いずれかの標準 OIDC クレームに SAML アサーションが対応している場合、その SAML アサーションは自動的に識別トークンに追加されます。 対応していないアサーションは、デフォルトでは無視されます。 SAML プロバイダーが他のアサーションを返す場合に、その情報をトークンに挿入するように App ID を構成できます。 ただし、必要以上に情報をトークンに追加しないようにしてください。通常、トークンは HTTP ヘッダーに入れて送信されるので、サイズが限られているからです。
App ID がアサーションにマップしようとする標準的な OIDC クレームは以下のとおりです。
name
email
locale
picture
これらの値の 1 つ以上が ID プロバイダー側で変更された場合、新しい値は、ユーザーが再びログインした後で使用できるようになりません。
App ID ではどのような SAML アサーションが求められますか?
このサービスでは、次の例のような SAML アサーションが求めれます。
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2202bbbbafa9d270d1c15990b738f4ab36139d463" InResponseTo="_e4a78780-35da-012e-8ea7-0050569200d8" Version="2.0" IssueInstant="2011-03-21T11:22:02Z" Destination="https://example.example.com/">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">idp_entityId</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="2.0" ID="pfx539c9774-de5c-5f52-0c3f-b1c2e2697a89" IssueInstant="2018-01-29T13:02:58Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>idp_entityId</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="one_of_supported_algo"/>
<ds:SignatureMethod Algorithm="one_of_supported_algo"/>
<ds:Reference URI="#pfx539c9774-de5c-5f52-0c3f-b1c2e2697a89">
<ds:Transforms>
<ds:Transform Algorithm="one_of_supported_algo"/>
<ds:Transform Algorithm="one_of_supported_algo"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="one_of_supported_algo"/>
<ds:DigestValue>huywDPPfOEGyyzE7d5hjOG97p7FDdGrjoSfes6RB19g=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>BAwNZFgWF2oxD1ux0WPfeHnzL+IWYqGhkM9DD28nI9v8XtPN8tqmIb5y4bomaYknmNpWYn7TgNO2Rn/XOq+N9fTZXO2RybaC49iF+zWibRIcNwFKCCpDL6H6jA5eqJX2YKBR+K6Yt2JPoUIRLmqdgm2lMr4Nwq1KYcSzQ/yoV5W0SN/V5t8EfctFoaXVPdtfHVXkwqHeufo+L4gobFt9NRTzXB0SQEClA1L8hQ+/LhY4l46k1D0c34iWjVLZr+ecQyubf7rekOG/R7DjWCFMTke822dR+eJTPWFsHGSPWCDDHFYqB4QMinTvUnsngjY3AssPqIOjeUxjL3p+GXn8IQ==</ds:SignatureValue>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">JohnDoe@gmail.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2018-01-29T12:59:58Z" NotOnOrAfter="2018-01-29T13:05:58Z">
</saml:Conditions>
</samlp:Response>
どのようなタイプのアルゴリズムが App ID でサポートされていますか?
App ID は、 RSA-SHA256 アルゴリズムを使用して XML デジタル署名を処理します。
App ID と連携する SAML ID プロバイダーの構成
App ID から ID プロバイダにメタデータを提供し、ID プロバイダから App ID にメタデータを提供することで、 App ID で動作するように SAML ID プロバイダを構成できる。
ID プロバイダーへのメタデータの提供
アプリを構成するには、SAML 互換の ID プロバイダーに情報を提供する必要があります。 その情報はメタデータ XML ファイルを介して交換されます。そこには、信頼関係の確立に使用される構成データも含まれています。
SAML は ID プロバイダーとして構成されるまで有効にすることはできません。
-
App ID ダッシュボードの**「管理」タブで、「SAML」行の「編集」**をクリックして、設定を構成できるようにします。
-
**「SAML メタデータ・ファイルのダウンロード (Download SAML Metadata file)」**をクリックします。 ID プロバイダーは、以下の情報がファイルにあることを想定しています。
メタデータ・ファイルに記載されている情報 変数 説明 EntityID
App ID が SAML 要求を発行したことを ID プロバイダーに通知するための ID。 Location URL
ユーザーが正常に認証された後に ID プロバイダーが SAML アサーションを送る場所。 Binding
ID プロバイダーが SAML 応答を送信する方法についての指示。 NameID Format
ID プロバイダが、アサーションのサブジェクトにどの識別子形式を送信する必要がある かを知る方法と、 App ID がユーザを識別する方法。 ID の形式は <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
でなければなりません。WantAssertionsSigned
アサーションに署名する必要があるかどうかを ID プロバイダーが検査する手段。 このサービスはアサーションが署名されていることを想定していますが、暗号化されたアサーションはサポートしていません。 KeyDescriptor
署名された SAML 要求の検証および応答の暗号化を行うように ID プロバイダーを構成するために使用できる SAML 署名証明書および暗号化証明書。 -
ID プロバイダーにデータを提供します。 ID プロバイダーがメタデータ・ファイルのアップロードをサポートしている場合は、そうすることができます。 サポートしていない場合は、プロパティーを手動で構成してください。 すべての ID プロバイダーが同じプロパティーを使用するとは限らないため、必ずしもそれらをすべて使用するわけではありません。
プロパティーの名前は ID プロバイダーの間で異なることがあります。
-
**「SAML 2.0 フェデレーション (SAML 2.0 Federation)」を「有効」**に切り替えます。
App ID へのメタデータの提供
ID プロバイダーからデータを取得し、それを App ID に提供することができます。 IBM Cloud または ID プロバイダーからアプリケーションへのログインを開始できます。
コンソールでメタデータを提供する
IBM Cloud UI からアプリケーションにログインするには、以下の手順に従います。
-
App ID ダッシュボードの**「SAML 2.0」**タブに移動します。
-
「プロバイダー名」 を追加します。 デフォルト名は SAML です。
-
ID プロバイダーから取得した以下のメタデータを**「SAML IdP からのメタデータの提供 (Provide Metadata from SAML IdP)」**セクションに入力します。
App IDに提供しなければならない情報。 変数 説明 Sign-in URL
認証のためにユーザーがリダイレクトされる URL。 これは SAML ID プロバイダーによってホストされます。 Entity ID
SAML ID プロバイダーのグローバルな固有名。 Primary certificate
SAML ID プロバイダーによって発行された証明書。 SAML アサーションの署名と検証のために使用されます。 プロバイダーごとに異なりますが、署名証明書を ID プロバイダーからダウンロードできる可能性があります。 証明書は .pem
形式でなければなりません。 -
オプション: 1 次証明書で署名検証に失敗した場合に使用される**「2 次証明書 (Secondary certificate)」**を入力します。 同じ署名鍵をそのまま使用する場合、証明書の認証が期限切れを理由に App ID でブロックされることはありません。
-
保存 をクリックします。
認証コンテキストを設定する必要がありますか? API を使用して行うことができます。
コンソールで IdP-initiated ログインを設定する
オプションとして、ID プロバイダーの UI からIBM Cloud上のアプリケーションにログインしたい場合は、IdP-initiatedlogin を有効にします。
コンソールでメタデータを提供する 」セクションのステップ1~4に従ってください。 そして、以下のプロセスを完了させる。
- IdP 開始ログインを有効にします。
- IdP リダイレクト URL を入力する。
- 保存 をクリックします。
APIでメタデータを提供する
-
/saml
API エンドポイントに GET 要求して、認証コンテキストや証明書など、現在の SAML 構成を表示する。サンプル・コード:
curl --request GET \ https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \ --header `Accept: application/json`
出力例:
{ "isActive": true, "config": { "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "certificate-example-pem-format" ], "displayName": "my saml example", "authnContext": { "class": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" ], "comparison": "exact" } } }
-
次の例の値をプロバイダーの情報に置き換えて、SAML 構成を作成します。 この例に示している値は必須ですが、表に示すように、より多くの情報を含めることもできます。
"config": { "authnContext": { "class": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue", "urn:oasis:names:tc:SAML:2.0:ac:classes:YourOtherChosenClassValue" ], "comparison": "sampleComparisonValue"} "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "primary-certificate-example-pem-format" "secondary-certificate-example-pem-format" ], "displayName": "my saml example", "signRequest": true , "encryptResponse": true }
SAML 構成変数 変数 説明 signInUrl
認証のためにユーザーがリダイレクトされる URL。 これは SAML ID プロバイダーによってホストされます。 entityID
SAML ID プロバイダーのグローバルな固有名。 displayName
SAML 構成に割り当てる名前。 primary-certificate-example-pem-format
SAML ID プロバイダーによって発行された証明書。 SAML アサーションの署名と検証のために使用されます。 プロバイダーごとに異なりますが、署名証明書を ID プロバイダーからダウンロードできる可能性があります。 証明書は .pem
形式でなければなりません。オプション : secondary-certificate-example-pem-format
SAML ID プロバイダーによって発行されたバックアップ証明書。 1 次証明書で署名検証に失敗した場合に使用されます。 注: 同じ署名鍵をそのまま使用する場合、証明書の期限切れを理由に認証がApp ID によってブロックされることはありません。 オプション : authnContext
認証コンテキストは、認証および SAML アサーションの品質を検証するために使用されます。 認証コンテキストを追加するには、クラス配列と比較ストリングをコードに追加します。 class
パラメーターとcomparison
パラメーターの両方を、適切な値で更新してください。 例えば、class
パラメーターはurn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue
のようになります。オプション : signRequest
signRequest
フラグを指定すると、テナントの SAML 署名秘密鍵を使用して署名した SAML 要求を ID プロバイダーに送信できます。 署名された要求を受け取るように SAML ID プロバイダーを構成するためには、ダウンロードできるメタデータ・ファイルのKeyDescriptor use="signing"
フィールドにある署名証明書が必要です。 デフォルトでは、要求の署名はoff
に設定されます。オプション : encryptResponse
encryptResponse
フラグを指定すると、認証要求の一部として、暗号化された応答を ID プロバイダーから受け取ることができます。 暗号化された応答を送信するように SAML ID プロバイダーを構成するためには、メタデータ・ファイルのKeyDescriptor use="encryption"
フィールドにある暗号化証明書が必要です。 デフォルトでは、応答の暗号化はoff
に設定されます。 -
/saml
APIエンドポイントに PUTリクエストを行い、ステップ2で作成した設定を App ID に提供する。 次の例を参照して、どのような要求になるかを確認してください。curl --request PUT \ https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \ --header `Accept: application/json` \ --data \ { "isActive": true, "config": { "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "primary-certificate-example-pem-format" ], "displayName": "my saml example", } }
APIによるIdP-initiatedログインの設定
IdP-initiated ログインを設定するには、以下の手順を実行する。
-
/saml
API エンドポイントに GET 要求して、認証コンテキストや証明書など、現在の SAML 構成を表示する。サンプル・コード:
curl --request GET \ https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \ --header `Accept: application/json`
出力例:
{ "isActive": true, "config": { "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "certificate-example-pem-format" ], "displayName": "my saml example", "authnContext": { "class": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" ], "comparison": "exact" } } }
-
次の例の値をプロバイダーの情報に置き換えて、SAML 構成を作成します。 この例に示している値は必須ですが、表に示すように、より多くの情報を含めることもできます。
"config": { "authnContext": { "class": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue", "urn:oasis:names:tc:SAML:2.0:ac:classes:YourOtherChosenClassValue" ], "comparison": "sampleComparisonValue" }, "idpInitEnabled": true, "idpRedirectUrl": "https://example.com/redirect/endpoint", "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "primary-certificate-example-pem-format" "secondary-certificate-example-pem-format" ], "displayName": "my saml example", "signRequest": true , "encryptResponse": true }
SAML 構成変数 変数 説明 signInUrl
認証のためにユーザーがリダイレクトされる URL。 これは SAML ID プロバイダーによってホストされます。 entityID
SAML ID プロバイダーのグローバルな固有名。 displayName
SAML 構成に割り当てる名前。 primary-certificate-example-pem-format
SAML ID プロバイダーによって発行された証明書。 SAML アサーションの署名と検証のために使用されます。 プロバイダーごとに異なりますが、署名証明書を ID プロバイダーからダウンロードできる可能性があります。 証明書は .pem
形式でなければなりません。DefaultRelayState
RelayState
の初期値。 この変数は、ID プロバイダーの設定で構成されます。 この変数は、ID プロバイダからの SAML リクエスト時にidpRedirectUrl
の代わりに URL のリダイレクトに使用できる。 両方の変数を設定すると、DefaultRelayState
の値が優先されます。 これらの変数のいずれかを設定しないと、IdP-initiatedのログインは失敗する。idpInitEnabled
IdP 開始ログインを有効にするかどうかを示すブール値。 idpRedirectUrl
このフィールドの値は、 null
、空の文字列、または有効なhttpまたはhttpsリダイレクト URL。 注 :このフィールドの値がNULLの場合、DefaultRelayState
をリダイレクト URL として設定する必要があります。 両方の変数を設定すると、DefaultRelayState
の値が優先されます。 これらの変数のいずれかを設定しないと、IdP-initiatedのログインは失敗する。オプション : secondary-certificate-example-pem-format
SAML ID プロバイダーによって発行されたバックアップ証明書。 1 次証明書で署名検証に失敗した場合に使用されます。 注: 同じ署名鍵をそのまま使用する場合、証明書の期限切れを理由に認証がApp ID によってブロックされることはありません。 オプション : authnContext
認証コンテキストは、認証および SAML アサーションの品質を検証するために使用されます。 認証コンテキストを追加するには、クラス配列と比較ストリングをコードに追加します。 class
パラメーターとcomparison
パラメーターの両方を、適切な値で更新してください。 例えば、class
パラメーターはurn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue
のようになります。オプション : signRequest
signRequest
フラグを指定すると、テナントの SAML 署名秘密鍵を使用して署名した SAML 要求を ID プロバイダーに送信できます。 署名された要求を受け取るように SAML ID プロバイダーを構成するためには、ダウンロードできるメタデータ・ファイルのKeyDescriptor use="signing"
フィールドにある署名証明書が必要です。 デフォルトでは、要求の署名はoff
に設定されます。オプション : encryptResponse
encryptResponse
フラグを指定すると、認証要求の一部として、暗号化された応答を ID プロバイダーから受け取ることができます。 暗号化された応答を送信するように SAML ID プロバイダーを構成するためには、メタデータ・ファイルのKeyDescriptor use="encryption"
フィールドにある暗号化証明書が必要です。 デフォルトでは、応答の暗号化はoff
に設定されます。 -
/saml
APIエンドポイントに PUTリクエストを行い、ステップ2で作成した設定を App ID に提供する。 次の例を参照して、どのような要求になるかを確認してください。curl --request PUT \ https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \ --header `Accept: application/json` \ --data \ { "isActive": true, "config": { "entityID": "https://example.com/saml2/metadata/706634", "signInUrl": "https://example.com/saml2/sso-redirect/706634", "certificates": [ "certificate-example-pem-format" ], "displayName": "my saml example", "authnContext": { "class": [ "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" ], "comparison": "exact" }, "idpInitEnabled": true, "idpRedirectUrl": "https://example.com/redirect/endpoint", } }
構成のテスト
SAML ID プロバイダーと App ID の間で構成をテストできます。
- 構成を保存したことを確認します。
- App ID ダッシュボードの**「SAML 2.0」タブに移動して、「テスト」**をクリックします。 新しいタブが開きます。
- ID プロバイダーによって既に認証されているユーザーを使用してログインします。
- フォームの入力を完了すると、別のページにリダイレクトされます。
- 認証に成功した場合: App ID と ID プロバイダーの間の接続は正常に機能しています。 ページには、有効なアクセス・トークンと識別トークンが表示されます。
- 認証に失敗した場合: 接続は切断されています。 ページには、エラーと SAML 応答 XML ファイルが表示されます。
SAML フレームワークは、複数のプロファイル、フロー、および構成をサポートしています。そのため、ID プロバイダーを正しく構成することが重要です。 問題が発生した場合は、 認証要求が失敗する可能性がある いくつかの一般的な理由を確認するか、 SAML 仕様 で詳細なエラー・コードを確認してください。