[認証] ワークスペースを使用して、Security Assertion Markup Language (SAML) プロトコルと互換性のある認証システムで Automation Config 内の SSO が動作するように構成できます。

SAML シングル サインオン (SSO) は、以下に示す目的のために、多くの組織が Automation Config の実装時に構成する機能です。

  • [ユーザーが同じ ID でサービスにログインするときにかかる時間の短縮。]組織によるいずれかのサービスにログインしたユーザーは、SSO を使用する他のサービスに自動的に認証されます。
  • [パスワードを入力する手間の軽減。]ユーザーが記憶する必要がある認証情報は 1 セットのみで、複数記憶する必要がありません。
注： 必要に応じて同時に複数のシステムを使用して、 Automation Config のユーザーを認証できます。たとえば、SAML ベースの IdP および LDAP ベースの IdP を使用すると同時に、複数のユーザー認証情報を RaaS サーバにネイティブに保存できます。ただし、 Automation Config では、複数の SAML プロバイダまたは複数の LDAP プロバイダを同時に構成することはできません。

SAML SSO と Automation Config の連携

Automation Config は、サポートしている認証統合のいずれかから正常な ID アサーションを受信すると、アサートされた ID の値に一致するユーザー ログイン情報を検索します。一致するログインが見つかると、関連付けられたユーザー アカウントのログインを実行します。

たとえば、あるユーザーの ADFS アサーションを Automation Config が受信し、構成された ID 属性の値が「fred」の場合、SSE はユーザー名が「fred」のログイン情報を検索します。見つかった場合は、関連付けられたユーザーがログインされます。見つからない場合、ログインは失敗します。

SAML 認証の用語

略語 定義
SAML

[Security Assertion Markup Language（SAML、サムエル）]

SAML は、認証および認証データを関係者間で交換するためのオープン プロトコル（標準とも呼ばれる）です。特に、ID プロバイダとサービス プロバイダの間でデータを交換するために使用されます。

SAML はブラウザ ベースのシングル サインオン (SSO) です。すべての通信は、ユーザー エージェント（ブラウザ）を介して実行されます。サービス プロバイダ（Automation Config など）と ID プロバイダ（Okta など）の間では、通信は発生しません。この分離により、サービス プロバイダを 1 つの（通常はパブリック）ドメインに置き、ID プロバイダは別のセキュアなネットワーク セグメントに置いて、複数のドメイン間で認証を行うことができます。
IdP

[ID プロバイダ]

IdP の役目は、認証情報に基づいてユーザーを識別することです。ID プロバイダは、SAML の仕様の ID プロバイダ部分に準拠したサービスを提供するソフトウェアです。IdP は通常、ログイン画面インターフェイスを提供し、認証が成功すると、認証されたユーザーに関する情報をサービス プロバイダに提示します。

Automation Config でサポートされる ID プロバイダは次のとおりです。

  • Google SAML
  • Okta*

* この表の後に示されている詳細を参照してください。
SP

[サービス プロバイダまたは証明書利用者]

SP（サービス プロバイダ）は通常、情報、ツール、レポートなどをエンド ユーザーに提供する Web サイトです。サービス プロバイダは、SAML の仕様 Automation Config のサービス プロバイダ部分に準拠したサービスを提供するソフトウェアです。Microsoft 製品（Azure AD や ADFS など）では、SP は証明書利用者と呼ばれます。

このシナリオでは、Automation Config がサービス プロバイダになります。Automation Config は、IdP からの認証アサーションを受け入れて、ユーザーにログインを許可します。

SP は、承認されたサービスのリストに表示されていない IdP を認証できません。承認済み IdP のリストを使用して SP を構成することは、構成プロセスの一部です。
SSO

[シングル サインオン (SSO)]

シングル サインオンは、認証されたユーザーに関する情報がサービスに渡されることで、ユーザーが 2 番目のサービスにログインすることが不要になる認証システムです。
SLO

[シングル ログアウト]

一部の IdP では、ユーザーが 1 つのサービスからログアウトすると、そのユーザーが認証されていた他のすべてのサービスからユーザーをログアウトします。

Automation Config では、現在 SLO がサポートされていません。
RBAC

[ロール ベースのアクセス制御]

ロール ベースのアクセス制御は、ロール ベースのセキュリティとも呼ばれる高度なアクセス制御手段であり、組織内でのユーザーの役割に基づいてネットワーク アクセスを制限します。RBAC でのロールは、従業員がネットワークに対して持つアクセス権のレベルを表します。

従業員は、自分の業務を効果的に実行するために必要な範囲でのみ、ネットワーク リソースにアクセスしたりタスクを実行したりすることができます。たとえば、レベルが下位の従業員は、責任を果たすために必要な場合以外、通常は機密データやネットワーク リソースにアクセスしません。

Automation Config では、[ロール] ワークスペースを使用して、SAML 構成で RBAC をサポートできます。ただし、ユーザーがローカル ユーザー データベースにユーザーとして追加されて [ロール] ワークスペースで管理されるためには、まず Automation Config にログインする必要があります。

Okta の要件

Okta を SSO 用に構成する際の考慮事項は次のとおりです。
  • セットアップ中に、[シングル サインオン URL] フィールドに SAML Assertion Customer Service (ACS) の URL を入力する必要があります。これは、末尾が /autho/complete/saml の SSC の URL です。例： http://xxx.x.x.x:8080/auth/complete/saml。
  • SAML 統合のユーザー インターフェイスは SSC が提供する必要があります。ユーザー インターフェイスが CDN または SSC 以外の他の Web サイトから提供されている場合は、統合が失敗します。
  • すべての SAML 応答に署名する必要があります。Okta では、[詳細設定] でこの設定を有効にできます。
  • SSC で構成されたすべての SAML 属性が存在し、SAML 応答で渡される必要があります。

前提条件

Automation Config で SAML を構成する前に、次の手順に従います。

  • SAML ID プロバイダ (IdP) をインストールし、それが実行されていることを確認します。
  • IdP によって提供される認証情報と構成データにアクセスできることを確認します。
  • IdP で承認済みのサービス プロバイダとして Automation Config を追加するには、証明書を生成します。Automation Config サービス プロバイダには、RSA キー ペアが必要です。Automation Config 向けに SAML を構成するときは、プライベート キーとパブリック キーの値を数か所に入力します。
    注： このキー ペアは、どのシステムでも生成できます。SSE サーバで作成する必要はありません。これらのコマンドは、openssl ユーティリティがインストールされているすべてのシステムで動作します。また、Salt を使用して自己署名証明書を生成することもできます。詳細については、 TLS Salt モジュールを使用した自己署名証明書を参照してください。
    証明書を作成するには、openssl genrsa -out cert.pem 2048 を使用して cert.perm というプライベート キーを生成します。openssl req -new -x509 -key cert.pem -out cert.pub -days 1825 コマンドを使用し、プロンプトに従って、プライベート キーに関連付けられたパブリック キーを作成します。これらのパブリック キーとプライベート キーのペアを記録し、残りの構成プロセスを進めるときにすぐに参照できるようにしてください。

SAML 構成の設定

  1. サイド メニューで [管理] >[認証] の順にクリックします。
  2. [作成] をクリックします。
  3. [構成タイプ] メニューの [SAML] を選択します。

    ワークスペースに、SAML 構成タイプでサポートされる設定が表示されます。

  4. [設定] タブで、Automation Config インストールに関する情報を使用して次のフィールドを構成します。
    • 名前
    • ベース URI
    • エンティティ ID
    • 会社名
    • 表示名
    • Web サイト
  5. [プライベート キー] フィールドには、Automation Config 用のサービス プロバイダ証明書を作成したときに生成したプライベート キーをコピーします。
  6. [パブリック キー] フィールドには、Automation Config 用のサービス プロバイダ証明書を作成したときに生成したパブリック キーをコピーします。
  7. 次のフィールドに、関連する連絡先情報を入力します。
    • 技術者の連絡先
    • サポートの連絡先
  8. [プロバイダ情報] セクションで、ID プロバイダ (IdP) に関するメタデータを使用して次のフィールドを構成します。
    • エンティティ ID
    • ユーザー ID - SSC で使用されるユーザー ID を表す IDP から SAML が受け取る属性の名前。
    • E メール - ユーザーのメール アドレスを表す IDP から SAML が受け取る属性の名前。SSC には、ユーザーの有効なメール アドレスが必要です。
    • ユーザー名 - ユーザーのユーザー名を表す IDP から SAML が受け取る属性の名前。これはユーザー ID とは異なるため、表されるユーザーを容易かつ迅速に認識できます。
    • URL
    • x509 証明書
    注： この情報は、IdP から提供されます。
  9. （オプション）Automation Config が SAML 属性ステートメントをユーザー プロファイルと照合してチェックするように指定するには、[属性ステートメント チェック] ボックスをオンにします。このオプションはデフォルトでオンになっています。
  10. [保存] をクリックします。

次の手順

SAML シングル サインオンを構成すると、次のことが可能になります。
  • AssertionCustomerService の URL（例：https://<your-sse-hostname>/auth/complete/saml）、および Automation Config に生成したパブリック (x509) 証明書とパブリック キーを IdP に提供します。
  • ユーザー、特にユーザー ID、メール アドレス、ユーザー名の属性マッピングを作成します。多くの組織では、一般にユーザーのメール アドレスが組織全体で一意であるため、この 3 つのすべての値を 1 つの属性としてメール アドレスにマッピングします。これらの属性をマッピングするプロセスは、各 SAML ID プロバイダによって異なります。これらの属性マッピングを作成する際のサポートについては、IdP のドキュメントを参照するか、管理者に確認してください。
  • ユーザーを Automation Config に追加します。デフォルトでは、新しいユーザーが Automation Config に登録されるのは、ユーザーが SAML を使用して初めてログインに成功した後です。または、手動でユーザーを追加して Automation Config に事前登録することもできます。[認証] ワークスペースからユーザーを手動で追加するには、[認証構成] のリストから SAML 構成を選択し、設定の [ユーザー] タブをクリックします。[作成] をクリックし、ユーザー認証情報を入力して、[ロール] を選択します。
    注： このユーザー名が正しいことを確認してください。ユーザーが作成されると、ユーザー名を変更することはできません。手動で作成されたユーザーは、最初のログインを実行する前に限り削除できます。ユーザーが最初にログインした後も、このワークスペースには削除ボタンが表示されますが、機能しません。
  • 一般的なユーザーとしてログインし、ログイン プロセスが想定どおりに動作することと、ロールと権限が正しいことを確認して、SAML 構成を検証します。Firefox および Chrome Web ブラウザで使用可能な SAML 追跡ツールを使用し、/var/log/raas/raas ログ メッセージを表示して、発生する可能性のあるエラーのトラブルシューティングを行います。
    注： 正常な SAML 認証によって最初のプロビジョニングが実行された後では、 Automation Config ユーザー インターフェイスまたは API を使用してユーザーを削除することはできません。