ワークスペースアイデンティティ

ユーザーのプライマリワークスペース ID は、マイクロアプリ、モバイルアプリ、仮想アプリ、仮想デスクトップ、コンテンツを含むすべてのワークスペースリソースフィードへのアクセスを許可します。Citrix Workspaceでは、ユーザーのプライマリIDプロバイダーを選択するための選択肢が組織に提供されます。

ID プロバイダー (IdP)

ID プロバイダーは、ユーザーの ID の最終的な権限です。ID プロバイダーは、パスワードポリシー、多要素認証ポリシー、ロックアウトポリシーなど、ユーザーの ID を保護および保護するためのポリシーを担当します。

クラウド時代以前は、組織では、ID プロバイダーの 1 つのオプション (Windows Active Directory) を使用していました。しかし、現在では、一意のユーザーアカウントを必要とするほぼすべてのシステムまたはサービスは、アイデンティティプロバイダーのように動作します。Facebook、LinkedIn、Twitter、Workday、およびGoogleは、それぞれサービス内のユーザーのアイデンティティの最終的な権限であるため、すべてのアイデンティティプロバイダーです。さらに、セキュリティに関する一般的な推奨事項は、ほとんど使用されないため、ID ごとに異なるパスワードを使用して、盗まれたパスワードの影響を制限することです。

アイデンティティへの従来のアプローチは、想像できる最悪のユーザーエクスペリエンスの1つを提供します。ユーザーは常に認証を要求されます。ユーザーは、サービスごとに一意の複雑なパスワードを覚える必要があります。ユーザーは、パスワードをリセットし、資格情報を忘れたためにアカウントをロック解除する貴重な時間を費やしています。

Citrix Workspaceでは、現状よりも優れた代替手段が提供されます。Citrix Workspaceでは、現在を含むオプションの増加するリストからプライマリIDを選択できます。

  • Windows Active Directory
  • Azure Active Directory
  • Okta
  • Citrix Gateway

ワークスペースアイデンティティ

Citrix Workspaceでは、IDブローカーのマイクロサービスを使用して、構成されたIDプロバイダーへの認証を管理します。ワークスペース認証が成功すると、リソースフィード µ-service はユーザーが使用できる承認されたリソースのリストを作成できます。

ただし、これらのサービスの多くは、異なる ID プロバイダを使用するため、ユーザーのプライマリワークスペース ID とは異なる ID を持っているか、または必要になります。シングルサインオン µ-service は、次のような適切なアプローチを使用して、ユーザーのプライマリワークスペース ID をリソース固有の ID に変換します。

  • SAML
  • kerberos
  • フォーム
  • 仮想スマートカード

プライマリおよびセカンダリIDのCitrix Workspaceアプローチでは、ユーザーが一度物理的に認証し、それ以降のすべての認証チャレンジが自動的に満たされるエクスペリエンスが作成されます。

アイデンティティブローカーリング

ID プロバイダーおよび関連する ID データベースは、ユーザーの ID の最終的な権限です。ただし、各 ID プロバイダーは異なります。各 ID プロバイダーには、ユーザーの ID に対して異なるパラメータ、ポリシー、および基準が組み込まれています。

Citrix Workspace内で、アイデンティティブローカー µ-serviceはプライマリ認証要求を構成されたアイデンティティプロバイダーにリダイレクトします。認証要求が ID プロバイダーに転送されると、ID プロバイダー内の認証ポリシーによって、ユーザーの認証方法が決定されます。これには、多くの場合、多要素認証ポリシーが含まれます。

ID プロバイダーがユーザーを正常に認証すると、ID ブローカー µ-service は成功した認証応答を受信します。このアプローチの利点は、組織がCitrix Workspaceに影響を与えることなく、IDプロバイダー内で認証ポリシーを変更できることです。

ID プロバイダーからの認証応答が成功するだけでなく、ID ブローカー µ-service は、ID プロバイダーから一意の情報を受信し、ユーザーに関する標準的な要求セットに変換します。

ユーザーに関するクレームは、単にユーザーを識別する情報です。この情報には、UPN、SID、GUID、電子メール、または ID プロバイダーのデータベースに含まれるその他の情報を指定できます。この要求により、Citrix Workspaceでは、ユーザーがアクセスを許可されているリソースとサービスのリストを生成できます。たとえば、ユーザーのプライマリIDがGoogle IDの場合、Citrix WorkspaceはGoogle IDを使用して、Google IDにリンクされていない他のリソースおよびサービス(Workday、SAP、Windows、Slackなど)への承認を制御します。別の方法で言いました, Citrix Workspaceでは, ユーザーは、Windowsを含むすべての承認されたリソースにログインするために単一のGoogle IDを使用することができます.

Citrix Workspace内では、アイデンティティブローカー µ-serviceは引き続き拡張され、プライマリIDプロバイダーの追加オプションが含まれます。ID ブローカー µ-service には、オンプレミスの場所から利用可能な ID プロバイダーや、ID ブローカー µ-Service がクラウドベースの ID プロバイダーを利用できる ID プロバイダーが含まれています。次の図は、Citrix Workspaceアイデンティティプラットフォームと現在のすべてのアイデンティティプロバイダーオプションの概要を示しています。これについては、後で詳しく説明します。

ワークスペースアイデンティティの概要

各アイデンティティプロバイダーは一意ですが、最終的には、各アイデンティティプロバイダーがCitrix Workspaceにユーザーに関するいくつかのことを伝えます。

  1. ユーザー名
  2. ユーザーは正常に認証されました
  3. ユーザーに関するクレーム

各 ID プロバイダーの詳細をよりよく理解するには、プライマリ ID プロバイダーに関する次のセクションを参照してください。

  • Active Directory
  • TOTP を使用したActive Directory
  • Azure Active Directory
  • Citrix Gateway
  • Okta
  • Google

Active Directory

構成すると、ユーザーはActive Directory 資格情報を使用してCitrix Workspaceに認証できます。

Active Directory IdP

Citrix WorkspaceをオンプレミスのActive Directory ドメインと統合するには、Workspaceがドメインコントローラーと通信できる必要があります。Cloud Connectorは、オンプレミス環境に高可用性Cloud Connectorセットを展開することにより、組織のCitrix Cloudサブスクリプションを使用して送信コントロールチャネルを確立します。送信コントロールチャネルにより、Citrix Workspaceでは、インバウンドファイアウォールポートを変更することなく、オンプレミスコンポーネントとの通信をポート443経由で安全にトンネルできます。

Cloud Connectorには、Active Directory oryドメインからユーザーおよびグループの情報をCitrix Workspaceで読み取れるADプロバイダーサービスが含まれています。ユーザーがCitrix Workspaceで認証されると、資格情報はCloud ConnectorのADプロバイダーサービスを介してオンプレミスのドメインコントローラーに送信されます。

Active Directory ポート

TOTP を使用したActive Directory

多くの組織では、ユーザー名とパスワードを使用してアプリケーションおよびデスクトップサービスへのアクセスを提供しても、セキュリティは十分ではありません。Citrix Workspaceには、「あなたが持っているもの」 (TOTPトークン)と「あなたが知っているもの」(パスワードである)を導入することにより、多要素認証を提供するクラウド配信時間ベースのワンタイムパスワード(TOTP)が組み込まれています。

TOTP は 30 秒ごとに変化するランダムな 6 桁のコードを生成します。このコードは、ユーザーのモバイルアプリとバックエンドインフラストラクチャ間で共有される秘密キーに基づいています。秘密鍵は、多要素認証の「あなたが持っているもの」の要素です。ランダムコードを生成するために、業界標準のセキュアハッシュアルゴリズムが秘密鍵と現在の時刻に適用されます。認証するために、モバイルアプリのコードをバックエンドインフラストラクチャのコードと比較します。

TOTP サービスに登録するには、各ユーザーは、モバイルデバイス上のオーセンティケータアプリ内に事前共有秘密キーを作成し、インストールします。

TOTP 登録を使用したActive Directory

ユーザーがTOTPマイクロサービスに正常に登録されると、ユーザーはトークンとActive Directory 資格情報を使用して、Citrix Workspaceへの認証を正常に行う必要があります。

TOTP 認証を使用したActive Directory

TOTPはCitrix Workspaceの機能として組み込まれているため、オンプレミス環境内でTOTPタイプのソリューションを設定および保守する複雑さが解消されます。Citrix Workspace内でこの機能を使用すると、管理者はサービスを有効にし、ユーザーはデバイスを登録します。

TOTPベースの多要素認証を有効にする場合は、次の点を考慮する必要があります。

  • オーセンティケータアプリ:TOTP は、業界標準のアルゴリズムを使用して時間ベースのトークンを生成します。ユーザーは、Citrix SSO、Microsoft Authenticator など、任意の数のモバイルアプリを使用してトークンを生成できます。
  • トークン数:ユーザーには、ユーザーアカウントごとに 1 つのトークン (キー) が許可されます。
  • デバイス数:ユーザーは 1 つのトークン (キー) に制限されますが、ユーザーは複数のデバイスにトークンをインストールできます。ただし、登録完了後にユーザーがQRコードまたは秘密鍵を明らかにできないため、インストールは登録フェーズ中に実行する必要があります。
  • デバイスの交換:ユーザーがモバイルデバイスを置き換えるたびに、TOTP サービスにデバイスを登録する必要があります。ユーザが TOTP 登録プロセスを再度実行すると、古い秘密鍵が削除されます。古い秘密キーを使用しているデバイスが正しいトークンを生成できず、その結果、Workspace 認証が失敗します。
  • トークンのリセット:管理者はユーザーのトークンを手動でリセットできます。リセットすると、ユーザは TOTP サービスに再登録しないと認証を完了できません。
  • 配備:すべての ID およびアクセス管理構成の変更と同様に、Workspace サブスクリプションで TOTP を有効化すると、すべてのユーザーに影響します。有効にすると、ユーザが TOTP サービスへの登録に成功するまで、新しい認証の試行が失敗します。

TOTP テックインサイトビデオには、ユーザおよび管理者エクスペリエンスの詳細が記載されています。

Azure Active Directory

Citrix Workspaceでは、ユーザーはAzureのActive Directoryアカウントで認証できます。認証は、ユーザー名とパスワードと同じくらいシンプルにすることも、Azure Active Directory 内で使用可能な任意の多要素認証ポリシーを利用することもできます。Citrix Workspace と Azure Active Directory の統合により、Azure Active Directory は認証プロセスを処理し、ユーザーのアイデンティティトークンを返します。

Azure Active Directory IdP

Citrix WorkspaceとAzure Active Directory を統合するために、Citrix Workspaceは自動的にAzure 内にエンタープライズアプリケーションを作成し、正しいアクセス許可を設定します。これらのアクセス許可には、次のものがあります (読み取り専用機能)。

  • サインインしてユーザー プロファイルを読み取る
  • すべてのユーザーの基本プロファイルを読む
  • すべてのユーザーの完全なプロファイルを読む
  • ディレクトリデータの読み取り
  • すべてのグループを読み取る

Azure Active Directory は、ユーザーを認証します。ユーザーが正常に認証されると、Azure は、正しいディレクトリ内でユーザーを一意に識別するためのユーザーに関する要求を含む、Azure アイデンティティトークンをCitrix Workspaceに提供します。

Citrix Workspaceでは、Azure Active Directory 要求を利用して、Citrix Workspace内のリソースとサービスに対するユーザーの認証が行われます。

リソースへのアクセスを許可するには、単一の「真実のソース」が必要です。真実の源は、承認決定の最終的な権限です。Azure Active Directory をプライマリユーザーディレクトリとして使用する場合、ワークスペースリソースの種類によって真実のソースが決まります。

  • Content Collaboration サービス:ユーザーファイルとコンテンツについては、Content Collaboration サービスが真実の源です。Azure Active Directory がワークスペースの ID プロバイダーである場合、Azure Active Directory ID とContent Collaboration アカウントは同じ電子メールアドレスを使用する必要があります。グループメンバーシップ情報に関しては、Content Collaboration サービスが真実の源です。グループメンバーシップ情報は、ユーザーの電子メールアドレスに基づいています。
  • Endpoint Management サービス:モバイルアプリケーションの場合、Endpoint Management サービスはActive Directory を真実のソースとして使用します。Azure Active Directory がワークスペースの ID プロバイダーである場合、Azure Active Directory ID には特定の Active Directory 要求 (SID、UPN、および変更されないimmutableID) が含まれている必要があります。これらの要求は、Azure Active Directory の ID を Active Directory の ID に関連付けます。Endpoint Management サービスがグループメンバーシップを使用している場合、Active Directory が真実のソースになります。
  • ゲートウェイサービス:SaaS および Web アプリケーションの場合、ゲートウェイサービスは Azure Active Directory を真実のソースとして使用します。ゲートウェイサービスは、Azure Active Directory ユーザーアカウントまたは Azure Active Directory ユーザーグループのメンバーシップを使用して、リソースへのアクセスを承認できます。
  • マイクロアプリサービス:マイクロアプリアプリケーションの場合、マイクロアプリサービスは Azure Active Directory を真実のソースとして使用します。マイクロアプリサービスは、Azure Active Directory ユーザーアカウントまたは Azure Active Directory ユーザーグループのメンバーシップを使用して、リソースへのアクセスを承認できます。
  • Virtual Apps and Desktops サービス:Windows ベースのリソース (VDI) には Active Directory ベースのユーザー ID が必要であるため、真実のソースは基盤となる Active Directory と Azure Active Directory の統合に依存します。
    • Azure Active Directory ユーザー ID には、特定の Active Directory 要求 (SID、UPN、および変更されないimmutableID) が含まれている必要があります。これらの要求は、Azure Active Directory の ID を Active Directory の ID に関連付けます。特定のユーザー ID については、Azure Active Directory が真実のソースです。
    • 承認の決定がグループメンバーシップに基づいている場合、真実のソースは Active Directory です。ワークスペースは、その後、Cloud Connectorを介して Active Directory にグループメンバーシップ要求を送信します。

Azure Active Directory 同期ツールを使用すると、Active Directory パラメーターを Azure Active Directory ID にリンクするプロセスが大幅に簡素化されます。

Azure Active Directory テクニカルインサイトビデオでは、FIDO2 YubiKey を使用する場合の管理者設定とユーザエクスペリエンスの詳細について説明します。

Citrix Gateway

ユーザーは、オンプレミスのCitrix Gatewayを使用してCitrix Workspaceに認証できます。Citrix Gateway認証は、Active Directory などのユーザー認証に単一のソースを使用する単純な認証ポリシーと、複数の認証プロバイダーとポリシーに依存するより複雑なカスケード認証ポリシーに対応します。

Citrix WorkspaceとCitrix Gatewayが統合すると、Citrix Gatewayが初期認証プロセスを処理します。Citrix Gatewayがユーザーの認証を検証すると、WorkspaceによってActive Directory 資格情報が検証され、承認されたサービスとリソースのリストが生成されます。

Citrix Gateway IdP

Citrix WorkspaceとCitrix Gatewayを統合するには、OAuth IdPポリシーをオンプレミスのCitrix Gateway内に作成する必要があります。これは、OAuth 2.0仕様に基づく認証プロトコルです。Citrix Workspaceでは、組織の一意のCitrix Gateway URLに接続して、アプリケーションのクライアントIDを参照してOpenID Connectアプリケーションにアクセスします。このURLは、共有秘密キーで保護されています。

Citrix Gatewayで構成されたOpenID Connectアプリケーションは、認証仮想サーバーにバインドされた高度な認証ポリシーを使用してユーザーを認証します。ユーザーがCitrix Gatewayに対して正常に認証されると、Citrix GatewayはユーザーのActive Directory 資格情報をCitrix Workspaceに返します。

Citrix Gatewayの技術洞察ビデオでは、管理者設定とユーザエクスペリエンスの詳細について説明します。

nFactorを使用すると、組織では、Citrix Gateway グループのメンバーシップ、デバイスの所有権、ユーザーの場所などの特性を考慮して、より動的な認証フローを作成できます。

たとえば、最も基本的な構成を使用して、組織はCitrix GatewayとCitrix Workspaceを統合して、Active Directory に認証を提供できます。

Citrix Gateway-Active Directory

この種類の構成には、Citrix Workspaceで構成されたOAuth IdPポリシーと、オンプレミスのActive Directory ドメイン用に構成されたLDAPポリシーが必要です。ただし、この基本認証ポリシーは、Citrix Gatewayを使用せずに実行できます。

多くの組織では、Active Directoryへの認証を行う前に、DUOなどのRADIUS展開に対してユーザーが認証する必要があります。これにより、Active Directory Active Directory 資格情報の保護に役立ちます。

Citrix Gateway-DUO

この設定では、最初に RADIUS 認証を検証するための認証ポリシーが必要です。成功すると、認証フローは次の認証要素(LDAP 認証)に進みます。

Citrix Gatewayでは、ユーザーの認証フローは現在のユーザーコンテキストに依存するコンテキスト認証を実装できます。たとえば、組織では、企業所有デバイスとユーザー所有のデバイスに対して、異なる認証ポリシーを実装できます。

Citrix Gateway-証明書

この構成では、Citrix Workspaceが認証要求をCitrix Gatewayに送信します。Citrix Gatewayは、企業所有のデバイスでのみ使用できるクライアントベースの証明書を要求します。証明書が使用可能で有効な場合、ユーザーは単に Active Directory パスワードを提供します。ただし、証明書が無効であるか、または存在しない場合(ユーザー所有デバイスの場合など)、Citrix GatewayはユーザーにTOTPコードとActive Directory 資格情報の入力を要求します。

コンテキスト認証の別の例は、Active Directory グループのメンバーシップに基づいて異なる認証ポリシーを提供します。

Citrix Gateway-ユーザーグループ

財務データ、個人データ、または知的財産データを操作するユーザーは、図の Group2 に示すように、より厳格な認証ポリシーに従う必要があります。

オンプレミスのCitrix GatewayをIDプロバイダーとして使用する場合、ユーザーはCitrix Workspaceでプッシュベース認証を利用できます。詳細は[プッシュ認証技術インサイトビデオ。]。(/ja-jp/tech-zone/learn/tech-insights/authentication-push.html)

構成されている認証ポリシーの種類にかかわらず、ユーザーが自分の身元を正常に検証すると、Citrix Gatewayは最初のCitrix WorkspaceリクエストにユーザーのActive Directory 資格情報で応答する必要があります。Citrix Workspaceで認証プロセスを完了し、承認されたリソースのリストを生成するには、各Active Directory ユーザーアカウントに次のパラメータが定義されている必要があります。

  • メール アドレス
  • 表示名
  • 共通名
  • sAMAccountName
  • ユーザー プリンシパル名
  • オブジェクト識別子 (OID)
  • セキュリティ識別子 (SID)

Okta

構成すると、ユーザーはOkta 資格情報を使用してCitrix Workspaceに認証できます。認証は、ユーザー名とパスワードと同じくらいシンプルにすることも、Okta 内で使用可能な多要素認証ポリシーを利用することもできます。Citrix WorkspaceとOkta の統合により、Okta は認証プロセスを処理し、ユーザーのIDとアクセストークンを返します。

Okta IdP

Citrix WorkspaceとOkta を統合するには、OOkta 内でOpenID Connectアプリケーションを作成する必要があります。Citrix Workspaceでは、組織の一意のOkta URLに接続し、アプリケーションのクライアントIDを参照してOpenID Connectアプリケーションにアクセスします。クライアントIDは共有秘密キーで保護されています。

OpenID Connect アプリケーションがユーザーを認証します。ユーザーがOktaに正常に認証されると、Okta はCitrix Workspaceに2つのセキュリティトークンを提供します。

  • アクセストークン:ユーザーがOkta リソース(OpenID Connectアプリケーション)にアクセスする権限を持っていることを証明するトークンで、継続的に再認証する必要がありません。
  • アイデンティティートークン:ユーザーの身元を証明するトークン。ID トークンには、認証されたユーザーに関するクレーム (情報) が含まれます。トークンは、改ざんされていないことを証明するためにエンコードされます。

これらのトークンを使用すると、Citrix WorkspaceがOpenID Connectアプリケーションにアクセスし、ユーザーのOkta IDに基づいて承認されたリソースのリストを生成できます。

リソースへのアクセスを許可するには、単一の「真実のソース」が必要です。真実の源は、承認決定の最終的な権限です。Okta をプライマリユーザーディレクトリとして使用する場合、Workspace リソースの種類によって真実のソースが決まります。

  • Content Collaboration サービス:ユーザーファイルとコンテンツについては、Content Collaboration サービスが真実の源です。Okta が Workspace のプライマリ ID プロバイダーである場合、Okta ID とContent Collaboration アカウントは同じ電子メールアドレスを使用する必要があります。グループメンバーシップ情報に関しては、Content Collaboration サービスが真実の源です。グループメンバーシップ情報は、ユーザーの電子メールアドレスに基づいています。このシナリオでは、Okta は Workspace の ID プロバイダーとしてのみ使用されます。
  • Endpoint Management サービス:モバイルアプリケーションの場合、Endpoint Management サービスはActive Directory を真実のソースとして使用します。Okta がワークスペースのプライマリ ID プロバイダーである場合、Okta ID には特定の Active Directory 要求 (SID、UPN、および GUID) が含まれている必要があります。これらの要求は、Okta アイデンティティを Active Directory ID に関連付けます。 Endpoint Management サービスがグループメンバーシップを使用している場合、Active Directory が真実のソースになります。
  • ゲートウェイサービス:SaaS および Web アプリケーションの場合、ゲートウェイサービスは Okta を真実のソースとして使用します。Gateway サービスは、Okta ユーザーアカウントまたは Okta ユーザー・グループのメンバーシップを使用して、リソースへのアクセスを許可できます。
  • マイクロアプリサービス:マイクロアプリアプリケーションの場合、マイクロアプリサービスは Okta を真実のソースとして使用します。Microapps サービスは、Okta ユーザーアカウントまたは Okta ユーザーグループのメンバーシップを使用して、リソースへのアクセスを許可することができます。
  • Virtual Apps and Desktops サービス:Windows ベースのリソース (VDI) には Active Directory ベースのユーザー ID が必要なため、真実のソースは基盤となる Active Directory と Okta の統合に依存します。
    • Okta ユーザー ID には、特定の Active Directory 要求 (SID、UPN、および GUID) が含まれている必要があります。これらの要求は、Okta アイデンティティを Active Directory ID に関連付けます。特定のユーザー ID の場合、Okta は真実の源です。
    • 承認の決定がグループメンバーシップに基づいている場合、真実のソースは Active Directory と Okta の間の同期パラメータに基づきます。Active Directory グループが Okta と同期され、Active Directory 要求 (SID) が含まれている場合、Okta は objectSID 属性を使用してグループの真実のソースになります。この Okta 属性は、Okta 仕様で定義された Active Directory グループに対してのみ返されます。ネイティブ Okta グループには、この属性が設定されないため、Active Directory が真実のソースになります。ワークスペースは、その後、Cloud Connectorを介して Active Directory にグループメンバーシップ要求を送信します。

Okta Active Directory 同期ツールを使用して、Active Directory パラメーターを Okta ID にリンクするプロセスが大幅に簡素化されます。Active Directory の要求は、Okta 内の次の命名規則に従う必要があります。

Okta-パラメータ

ID プロバイダーとしての Okta の設定と構成については、 [Okta テックインサイトビデオ。]を参照してください。(/ja-jp/tech-zone/learn/tech-insights/okta.html)

ワークスペースアイデンティティ