Alteryx Server 認証を設定する
[システム設定] > [Gallery Authentication] (Galleryの認証)ページで、Serverへのアクセス管理に使用する認証方法を設定します。
まず、Serverに使用する認証方式を選択します。次に、選択した方法のセットアップ手順に進みます。
認証タイプの選択
Serverは、ビルトイン認証、統合Windows認証(Kerberosサポート付きまたはKerberosサポートなし)、およびSAML認証をサポートしています。
Built-in(ビルトイン): Serverへのアクセスに使用する E メールアドレスとパスワードをユーザーが選択して指定します。
Integrated Windows authentication: ユーザーが内部ネットワーク資格情報でServerにアクセスできるようにします。
Integrated Windows authentication with Kerberos(統合Window Kerberos認証): Kerberos認証プロトコルを使用して、ユーザーが内部ネットワーク資格情報でServerにアクセスできるようにします。統合Windows認証と統合Windows Kerberos認証のセットアップ手順は同じです。詳細については、「 選択した認証タイプのセットアップを完了する 」に進み、 「統合Windows認証のセットアップ」を選択してください。
SAML authentication(SAML認証): ユーザーが認証IDプロバイダー(IDP)資格情報を使用してServerにアクセスできるようにします。
警告
Serverは、設定後の認証タイプの変更をサポートしていません。これを行うとServerの機能が損なわれるおそれがあります。認証タイプを変更する場合は、アカウントチームに連絡し、サポートについてご相談ください。
選択した認証タイプのセットアップを完了する
認証タイプごとにセットアップが異なります。セットアップの手順を完了させるために、選択した認証タイプを選択します。
ステップ 1.ビルトイン認証の既定のGallery管理者を設定
[ビルトイン]認証を選択した後、[Gallery Authentication] (Galleryの認証)ページの下端で[Default Gallery Administrator] (既定のGallery管理者)を作成します。Gallery(Server)管理者は、ユーザーやワークフローなどを管理します。ビルトイン認証の場合は、管理者のEメールアドレスを入力します。
システム設定で残っている画面の設定を完了し (これら画面の詳細については、「 Server UI 」および「 Engine」のヘルプページを参照)、 Finish(完了) を選択します。
ステップ 2.Gallery管理者アカウントの作成を完了
Gallery管理者アカウントの作成を完了するには、Serverのサインインページに移動します。この操作は、[システム設定] > [Status] (ステータス)ページに表示されているServerへのリンクを選択するか、インターネットブラウザにServerへのURLを入力して行います。
[Sign In] (サインイン)を選択します。
サインインページで、[新しいアカウントにサインアップ]を選択します。
氏名 (名)と氏名 (姓)を入力し、ドロップダウンメニューからタイムゾーンを選択します。
[システム設定] > [Gallery Authentication]ページの[Default Gallery Administrator]で指定したEメールアドレスを[Eメール]に入力します。
Password (パスワード) で、アカウントパスワードを作成します。パスワードには以下が含まれる必要があります:
8文字以上
1 つ以上の文字
1 つ以上の数字
大文字と小文字
1 つ以上の特殊文字
[サインアップ]を選択します。
これで、Gallery(Server)管理者としてログインできました。サインアップフォームに入力した資格情報は、今後の資格情報として保存されます。Serverユーザーを追加できるようになりました。Serverユーザーを追加を参照してください。
重要
Windows認証でAWSを利用する場合、認証を維持するにはTCP接続が同じ送信元ポートを維持する必要があります。このため、アプリケーションロードバランサーではなく、ネットワークロードバランサーまたは従来のロードバランサーの使用を推奨します。
注記
統合Windows認証と統合Windows Kerberos認証の設定の違いは、Active Directoryでユーザーの認証に使用されるプロトコルです。統合Windows認証オプションではNTLMが使用されますが、統合 Windows Kerberos 認証ではNTLMがKerberosに置き換えられます。
Server自体に特別な設定は必要ありませんが、KerberosオプションではActive Directoryドメインに適切に設定された Kerberos領域とKDCが存在する必要があります。
ステップ 1.Windows認証の既定のGallery管理者を設定
[Integrated Windows authentication] (統合Windows認証)を選択した後、[Gallery Authentication] (Galleryの認証)ページの下端で[Default Gallery Administrator] (既定のGallery管理者)を作成します。Gallery(Server)管理者は、ユーザーやワークフローなどを管理します。Integrated Windows authentication(統合Windows認証)の場合は、 format: domain\username
(ドメイン \ ユーザー名)の形式でユーザーアカウントを入力します。
システム設定で残っている画面の設定を完了し (これら画面の詳細については、「 Server UI 」および「 Engine」のヘルプページを参照)、 Finish(完了) を選択します。
ステップ 2.サーバーにアクセス
これで既定のGallery (Server)管理者がServerにアクセスできるようになりました。この操作は、[システム設定] > [Status] (ステータス)ページに表示されているServerへのリンクを選択するか、インターネットブラウザにServerへのURLを入力して行います。これでGallery (Server)管理者としてログインし、Serverユーザーを追加する準備ができました。Serverユーザーを追加を参照してください。
マルチドメインのサポート
Serverは、ドメインが複数ある場合のWindows認証をサポートしています。これを有効にするために Server 側に必要な設定はありませんが、これらの機能と権限はドメイン全体に存在していることが必要です。
Serverが実行するドメインには、他のドメインユーザーと同じ信頼ポリシーを設定して、Active Directoryがユーザー権限を解決して決定できるようにする必要があります。
両方のドメインが同じフォレストに属している必要があります。
両方のドメインのCN=UsersおよびCN=Computersコンテナからすべての属性をAlteryx serviceが読み取ることができる必要があります。Alteryx serviceは、インストールされているサーバー上のローカルシステムアカウントで実行されます。ローカルシステムを使用する代わりに専用サービスアカウントを定義する場合、両方のドメインの認証を有効にするには、両方のコンテナからすべての属性を読み取る権限をアカウントに設置する必要があります。
シングルサインオン (SSO) 用に SAML 認証を設定するには、アイデンティティプロバイダー (IDP) が SAML をサポートしている必要があります。
重要
ServerのSAML認証を設定する前に、IDPにサービスプロバイダーとしてServerを追加する必要があります。IDPに必要な情報は次のとおりです。
ACS Base URL (ACSベースURL) (http://localhost/webapi/Saml2/Acs など)。
SP Entity ID (SPエンティティID) (http://localhost/webapi/Saml2 など)。
バージョン2022.3からは、更新されたサービスプロバイダーエンドポイントをWeb APIサービスを介して使用することになります。なお、以前のエンドポイントを使用した既存の設定は引き続き動作し、現時点では既存のAlteryx ServerでSAMLの使用を継続するために必要なアクションはありません。詳細については、Server 2022.3リリースノートを参照してください。
また、IDPではユーザーを認証するため、IDP内の対応するフィールドに、Eメール、名、姓の属性ステートメントのマッピングが必要になることがあります。
IDP署名証明書は、SHA-256以上の署名アルゴリズムで設定する必要があります。
IDPに必要なメタデータを取得するためのオプションを選択します。SAML using an IDP Metadata URL (IDP メタデータ URL) を使用して SAML) を設定するか、または X509 certificate and IDP SSO URL (X509 証明書と IDP SSO URL) を設定できます。
[SAML IDP Configuration] (SAML IDP設定)を完了します。
ACS Base URL (ACSベースURL): SAMLメッセージを受け入れてセッションを確立するアサーションコンシューマーサービスのURL。
IDP URL: IDPで設定されたAlteryxアプリケーションのURL(IDPエンティティIDとも呼ばれます)。
IDP Metadata URL (IDPメタデータURL): IDPによって提供されるURLで、IDP SSO URL と、Alteryx認証サービスを設定するためのX509証明書が含まれています。
IDP SSO URL: IDPによって提供されるSSO URLであり、Alteryx認証サービスはこれを使用してIDPにログインします。
X509 certificate (X509 証明書): IDPによって提供される公開証明書であり、Alteryx認証サービスとの安全な通信のために使用されます。
Request Signing(リクエストの署名): リクエスト署名を必要とするIDPの場合、[Request Signing]設定を有効にすることができます。この設定には、関連するRSA秘密鍵を持つ有効な署名付き証明書がWindows証明書ストアにインストールされている必要があります。
SSL/TLS Certificate Hash (SSL/TLS証明書ハッシュ): 証明書と秘密鍵のインストールが完了したら、SSL/TLS証明書の一意のハッシュを指定します。
Encrypt Assertions (アサーションの暗号化): 暗号化されたSAMLアサーションを使用する必要があるIDPの場合は、[Encrypt Assertions]チェックボックスをオンにします。この設定では、Server UIを設定する前に、関連するプライベートキーを持つ署名付きCA証明書がWindows証明書ストアにインストールされている必要があります。自己署名証明書はサポートされていません。
Decryption Certificate Hash (復号化証明書ハッシュ): CA証明書とプライベートキーをインストールした後、SAMLアサーションの一意のハッシュを入力します。
FIPSおよび非FIPS環境
FIPS環境
FIPS環境では、次の暗号化XML方式がサポートされています。
<EncryptedData> <KeyInfo> <EncryptedKey><!-- Encrypted symmetric key here --></EncryptedKey> </KeyInfo> <!-- Encrypted Assertion here --> </EncryptedData>
次の方式はサポートされていません。
<EncryptedData> <KeyInfo> <RetrievalMethod URI="#key123"/> </KeyInfo> <!-- Encrypted Assertion here --> </EncryptedData> <EncryptedKey Id="key123"> <!-- Encrypted symmetric key here (typically 100-300 bytes) --> </EncryptedKey>
非FIPS環境
非FIPS環境では、上記の両方の暗号化方式がサポートされています。
Verify IDP (IDPの検証): 選択してブラウザのウィンドウを開き、ログインしてIDP設定をテストし、既定のServer管理者を設定します。
SAMLでの既定のGallery管理者の設定
サイトを管理する (ユーザーやワークフローの管理など) には、Gallery (Server) 管理者アカウントを作成する必要があります。SAML認証の場合は、[Verify IDP]を選択してIDP設定をテストし、フィールドにIDP資格情報を入力します。
これで、Server管理者としてログインできました。Serverユーザーを追加できるようになりました。Serverユーザーを追加を参照してください。
注記
管理者は、Azure Active Directory (Azure AD)とSCIMプロトコルを使用して、ユーザーとグループのアクセス権をServerに同期できます。これにより管理者は、IDプロバイダーからのユーザーとグループの権限とServerへのアクセス権を、信頼できる単一の情報源として管理できるようになりました。Azure ADからServesへのユーザーとグループの同期は、自動的に行われます。これにより、新しいServerユーザーのオンボーディングやオフボーディングがより迅速になります。
認証方法としてSAMLを使用しているお客様は、この機能を利用できます。SCIMをサポートしているIDプロバイダーであれば、この機能を利用できます。なお、Alteryxが公式にテストし、サポートしているのはAzure ADのみです。
SCIM設定の詳細については、Alteryx Serverの設定を参照してください。
Azure Active Directoryを使用してSCIM用のAlteryx Serverを構成する方法については、「 Azure Active Directoryを使用してSCIM用のAlteryx Serverを構成する」を参照してください。
Azure SCIMの詳細については、Microsoft Azureのドキュメントを参照してください。
AzureでSCIMエンドポイントを導入してテストする方法については、「チュートリアル: Azure Active DirectoryでサンプルSCIMエンドポイントを開発する」を参照してください。
Alteryx Serverと併せて使用するAzure SCIMに関する、最も基本的な質問への回答を参照してください。
SCIMを有効にすると、Azure(または他のIDP)のエンティティはServerと同期され、これらのエンティティがその後変更されるとServerの関連オブジェクトも変更されます。IDPにも存在するServer内の既存ユーザーとグループは、IDPからの変更にリンクして更新されます。IDPは、これらのオブジェクトの信頼すべき情報源として機能します。たとえば、ユーザー「John Smith」が両方に存在し、SCIMを有効にした場合、Serverで「John Smith」を「John Doe」に変更しても、次回の同期で元の「John Smith」に変更されます。
グループは名前でリンクし、ユーザーはEメールでリンクします。
Serverにのみ存在するローカルユーザーおよびグループは、IDPの範囲外であり、Serverによって管理されるオブジェクトのままで存在します。
一部の文字がSCIMからServerに転送されない場合がありますが、その動作はIDPによって異なります。IDPでグループまたはユーザーオブジェクトの名前に特殊文字、制限文字、あるいは予約文字が許可されている場合、その文字はServerに同期されます。オブジェクト名について特定の文字を明示的に許可または禁止することはありません。
Serverは、SCIMのためのIDPへの接続を開始しません。代わりに、IDPがServerへの接続を開始するために使用する、多数のAPIエンドポイントとアクセストークンを提供します。これらのエンドポイントは、Postmanなどの標準APIテストツールを使用して手動でテストできます。
Server監査ログは、ユーザーとグループのオブジェクトに対するすべての変更を監査します。これには、SCIMによって行われた変更も含まれます。
SCIMでは、アセットの所有権、ロール、権限は更新されません。そのため、既存のユーザーとグループは、現在所有しているアセットと、それらに割り当てられているロールと権限を保持します。
Serverのグループ設定によって権限が決まります。Azure Active Directoryに権限は保存されません。
ADグループをAzureからServerに同期すると、管理者はServerで新しく作成されたグループの権限を設定できます。その後、そのADグループに新しいユーザーを追加すると、SCIMは自動的にそのユーザーをServerのグループに追加します。その後、そのユーザーはそのServerグループに基づいて権限を取得します。
SCIMの機能には、ユーザーとグループによるAzure ADからServerへのアクセスの許可のみが含まれます。この同期には、データベースなど、Azure内の他のアセットに対する権限は含まれません。そのため、すべてのデータに対してDCMまたはServerデータ接続を使用する必要があります。
SCIMを含まない古いバージョンのServerにロールバックする必要がある場合、SCIMは機能せず、Serverを再アップグレードするまで使用できません。
SCIMを設定する前の状態からDBバックアップを復元する場合は、復元後にSCIMを再設定し、初期同期を実行する必要があります。
SCIMを使用しているServerのバージョンにバックアップを復元する必要がある場合は、IDP側から完全な再同期を実行して、データベースを再度IDPと同期させる必要があります。
SCIMを使用してユーザーを無効にした場合、スケジュールの動作はユーザーを無効化または削除したときと同様になります。Server UIまたはAPIを介してユーザーを無効化した場合や、APIを介してユーザーを削除した場合と同じように動作します。詳細については、ユーザーを無効化を参照してください。
同期時間はIDPによって異なり、設定可能な場合があります。Azureの場合、同期には最大40分かかることがあり、これは設定で変更できない静的な値です。
Azureでは広範なテストを行い、Oktaでは限定的にテストを実施しました。ただし、Oktaプロビジョニングエージェントは有料の顧客にのみ提供されているため、テストできませんでした。他のIDPは機能するはずですが、未検証です。