IBM Cloud Docs
SAML

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 トークンを作成します。 次の表にある例を確認してください。

SAML トークンで返される情報のタイプを理解する。
情報のタイプ
認証 ユーザーの認証にパスワードが使用されたのか、MFA が使用されたのか、それとも別の方法が使用されたのか。
属性 ユーザーの所属グループや何らかの設定などの属性。
権限の決定 ユーザーには、他のユーザーと比べて多くの権限が付与されることも、少ない権限が付与されることもある。

フローの概要

ユーザーの認証に SAML フレームワークを使用する場合でも、アプリケーションとのセキュリティー・トークンの交換には、App ID は、より新しい OIDC プロトコルを使用します。 次の図を参照して、情報の詳しいフローを確認してください。

SAML エンタープライズ認証
* エンタープライズ SAML 認証フローはどのように機能するか

  1. ユーザーはアプリケーション上のログインページまたは制限されたリソースにアクセスし、 App ID SDKまたはAPIのいずれかを介して App ID /authorization エンドポイントへのリクエストを開始する。 ユーザーが許可されていない場合、認証フローは App ID へのリダイレクトから始まります。
  2. App ID が SAML 認証要求 (AuthNRequest) を生成し、ブラウザーはユーザーを SAML ID プロバイダーに自動的にリダイレクトします。
  3. ID プロバイダーが SAML 要求を解析し、ユーザーを認証し、そのユーザーのアサーションを含む SAML 応答を生成します。
  4. ID プロバイダーが、SAML 応答と一緒にユーザーと応答を App ID にリダイレクトします。
  5. 認証が成功した場合、App ID は、ユーザーの許可と認証を表すアクセス・トークンと識別トークンを作成し、それらをアプリに返します。 認証が失敗した場合、App ID は ID プロバイダーのエラー・コードをアプリに返します。
  6. アプリまたは保護リソースへのアクセスがユーザーに許可されます。

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 プロバイダーとして構成されるまで有効にすることはできません。

  1. App ID ダッシュボードの**「管理」タブで、「SAML」行の「編集」**をクリックして、設定を構成できるようにします。

  2. **「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 の形式は &lt;saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"&gt; でなければなりません。
    WantAssertionsSigned アサーションに署名する必要があるかどうかを ID プロバイダーが検査する手段。 このサービスはアサーションが署名されていることを想定していますが、暗号化されたアサーションはサポートしていません。
    KeyDescriptor 署名された SAML 要求の検証および応答の暗号化を行うように ID プロバイダーを構成するために使用できる SAML 署名証明書および暗号化証明書。
  3. ID プロバイダーにデータを提供します。 ID プロバイダーがメタデータ・ファイルのアップロードをサポートしている場合は、そうすることができます。 サポートしていない場合は、プロパティーを手動で構成してください。 すべての ID プロバイダーが同じプロパティーを使用するとは限らないため、必ずしもそれらをすべて使用するわけではありません。

    プロパティーの名前は ID プロバイダーの間で異なることがあります。

  4. **「SAML 2.0 フェデレーション (SAML 2.0 Federation)」「有効」**に切り替えます。

App ID へのメタデータの提供

ID プロバイダーからデータを取得し、それを App ID に提供することができます。 IBM Cloud または ID プロバイダーからアプリケーションへのログインを開始できます。

コンソールでメタデータを提供する

IBM Cloud UI からアプリケーションにログインするには、以下の手順に従います。

  1. App ID ダッシュボードの**「SAML 2.0」**タブに移動します。

  2. 「プロバイダー名」 を追加します。 デフォルト名は SAML です。

  3. 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 形式でなければなりません。
  4. オプション: 1 次証明書で署名検証に失敗した場合に使用される**「2 次証明書 (Secondary certificate)」**を入力します。 同じ署名鍵をそのまま使用する場合、証明書の認証が期限切れを理由に App ID でブロックされることはありません。

  5. 保存 をクリックします。

認証コンテキストを設定する必要がありますか? API を使用して行うことができます。

コンソールで IdP-initiated ログインを設定する

オプションとして、ID プロバイダーの UI からIBM Cloud上のアプリケーションにログインしたい場合は、IdP-initiatedlogin を有効にします。

コンソールでメタデータを提供する 」セクションのステップ1~4に従ってください。 そして、以下のプロセスを完了させる。

  1. IdP 開始ログインを有効にします。
  2. IdP リダイレクト URL を入力する。
  3. 保存 をクリックします。

APIでメタデータを提供する

  1. /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"
       }
       }
    }
    
  2. 次の例の値をプロバイダーの情報に置き換えて、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 に設定されます。
  3. /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 ログインを設定するには、以下の手順を実行する。

  1. /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"
       }
       }
    }
    
  2. 次の例の値をプロバイダーの情報に置き換えて、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 に設定されます。
  3. /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 の間で構成をテストできます。

  1. 構成を保存したことを確認します。
  2. App ID ダッシュボードの**「SAML 2.0」タブに移動して、「テスト」**をクリックします。 新しいタブが開きます。
  3. ID プロバイダーによって既に認証されているユーザーを使用してログインします。
  4. フォームの入力を完了すると、別のページにリダイレクトされます。
    • 認証に成功した場合: App ID と ID プロバイダーの間の接続は正常に機能しています。 ページには、有効なアクセス・トークンと識別トークンが表示されます。
    • 認証に失敗した場合: 接続は切断されています。 ページには、エラーと SAML 応答 XML ファイルが表示されます。

SAML フレームワークは、複数のプロファイル、フロー、および構成をサポートしています。そのため、ID プロバイダーを正しく構成することが重要です。 問題が発生した場合は、 認証要求が失敗する可能性がある いくつかの一般的な理由を確認するか、 SAML 仕様 で詳細なエラー・コードを確認してください。