Things Cloud 認証シングルサインオン

シングルサインオン

はじめに

Things Cloud はシングルサインオン (SSO) 機能を提供します。これにより、ユーザーは OAuth2 プロトコルを使用して単一のサードパーティ認可サーバー (Azure Active Directory (AAD) など) にログインできるようになります。現在、認証コード付与は JWT 形式のアクセストークンおよびIDトークンでサポートされています。SAML はサポートされていません。
標準のSSOに加えて、Things Cloud では認可サーバーからのアクセストークンをベアラートークンとして直接使用して、プラットフォームリソースにアクセスすることもできます。詳細については、認可サーバーからのアクセストークンの使用を参照してください。

必要条件

SSO機能を使用するには、次の要件を満たす必要があります。

利用中の認可サーバーが OAuth2 認証コード付与に対応している
アクセストークンは JWT として発行され、トークンの内容がわかる
JWTは、一意のユーザー識別子、「iss」（発行者）、「aud」（対象者）、「exp」（有効期限）フィールドで構成されている
すべてのマイクロサービスは、Microservice Java SDKバージョン10.4.6（推奨）以上で構築されています。カスタムビルドのマイクロサービスについては、セキュリティを参照
オンプレミスインストールの場合、ドメインベースのテナント解決が適切に構成されている
エンタープライズテナント（親テナント）の場合、基本構成でエンタープライズドメインをリダイレクト URI として設定する必要がある。SSO プロバイダが許可されたドメインのリストを持っている場合は、エンタープライズドメインをそのリストに追加する必要がある
※「自身のユーザー管理」の読み取り権限以上のロールをユーザーに割り当てる必要があります。割り当てられない場合、ユーザーはログインできません。
SSO 機能は Cookie テクノロジーに基づいて構築されているため、ユーザーはブラウザの設定で Cookie を有効にする必要がある

構成設定

SSO機能を有効にするには、管理者が認可サーバーとの接続を設定する必要があります。これは、管理アプリケーションで行われます。

構成アクセス

SSO 構成は、マネジメントテナントによって排他的にアクセスできるように構成できるため、他のテナントが構成にアクセスすることはできません。このようなテナントのユーザーは構成を更新できません。これにより、SSO が正しく設定されず、他のユーザーがSSO 経由でログインできなくなるリスクがなくなります。
マネジメントテナントは、特定のテナントのSSO 構成へのアクセスを許可または制限できます。設定アクセスの詳細については、Things Cloud OpenAPI仕様内のログインオプションAPIを参照してください。

構成アクセスの詳細については、Things Cloud OpenAPI仕様のログインオプション API を参照してください。

構成ビュー

認証ページで シングルサインオン タブをクリックします。このタブは、SSO 構成にアクセスできるテナントにのみ表示されることに注意してください。

左上でテンプレートを選択できます。選択したオプションは、パネルの外観に影響します。デフォルトのテンプレートは「カスタム」です。これにより、OAuth2 認証コード付与を使用する事実上すべての認可サーバーで非常に詳細な構成が可能になります。他のテンプレートは、well-known かつサポートされている認可サーバーの簡略化されたビューを提供します。次の手順では、最初に「カスタム」テンプレートの使用方法を定義し、続いてAzure Active Directory 専用のビューを定義します。

カスタムテンプレート構成

認証ページの シングルサインオン タブで、テンプレートとして「カスタム」（デフォルト）を選択し、OAuth2 認証コード付与を使用して任意の認可サーバーとの接続を構成します。

OAuth プロトコルは HTTP リクエストとリダイレクトの実行に基づいているため、一般的なリクエスト構成が提供されます。

カスタム認可リクエスト

接続の構成方法

シングルサインオン ページの最初の部分は、リクエスト構成で構成されます。ここでは、トークンおよびリフレッシュリクエストの場合の HTTP リクエストアドレス、リクエストパラメーター、ヘッダーおよび本文を構成できます。認証方法は、GET、token、および POST リクエストによるリフレッシュメソッドとして実行されます。

備考

各リクエストの本文フィールドは、プレースホルダーに値を入力した後、リクエスト内で「そのまま」送信されることに注意してください。これは、Things Cloudによってエンコードされていないことを意味します。多くの認可サーバーでは、本文内の値をURLエンコード（x-form-urlencoded）する必要があります。これは、すでにエンコードされた値を本文フィールドに入力することで実現できます。

ログアウトリクエストの指定は任意です。フロントチャネルシングルログアウトを実行します。リクエストパラメーターとして構成した場合、ユーザーは Things Cloud からログアウトした後、定義された認可サーバーのログアウト URL にリダイレクトされます。認可サーバーとの統合にOpenID Connect 標準を使用する場合、IDトークンはログアウトリクエストの id_token_hint パラメータとして渡す必要があります。　

カスタムログアウトリクエスト

シングルサインオン ページの基本セクションは、次の構成設定で構成されます。

カスタム基本構成

フィールド	説明
リダイレクトURI	リダイレクトパラメーター。リクエスト定義で ${redirectUri} プレースホルダーとして使用できます。「ユーザーインターフェースアプリケーションへのリダイレクト」が有効になっている場合、リダイレクト URI は不要です。リダイレクト URI は、現在使用しているアプリケーションに自動的に設定されます。
ユーザーインターフェースアプリケーションへのリダイレクト	リダイレクト URL は、ユーザーがログイン時に使用したアプリケーションに自動的に設定されます。有効にする場合、認可サーバーに有効なリダイレクト URI（例：https://cumulocity.com/apps/*）を設定してください。このオプションを有効にすると、SSO 構成中に発生したエラーが UI アプリケーションに正しく表示されるようになります。
クライアントID	OAuth接続のクライアントID。リクエスト定義で ${clientId} プレースホルダーとして使用できます
トークン発行者	OAuthトークン発行者
ボタン名	ログインページのボタンに表示される名前
プロバイダー名	プロバイダーの名前
対象	JWTの予期されるaudパラメータ
ログインページに表示	ログインオプションが有効かどうかを示します

ユーザーがログインするたびにアクセストークンとIDトークンの内容が検証され、これが Things Cloud プラットフォームへのユーザーアクセスの基礎となります。次のセクションでは、JWTクレームとプラットフォームへのアクセスの間のマッピングについて説明します。

動的アクセスマッピングのソース では、管理者は JWT クレームが取得されるソースを指定できます。アクセストークンまたは ID トークンのいずれかです。

カスタムアクセスマッピング

動的アクセスマッピングの原則 では、次のいずれかのオプションを選択できます。

ユーザー作成時にのみ動的アクセスマッピングを使用：新規ユーザーがログインして最初のロールを入力するときのみ、動的アクセスマッピングが使用されます。ユーザーがすでに Things Cloud に存在する場合、ロールは上書きも更新もされません。
以下のルールで選択されたロールは、各ログイン時にユーザーに再割り当てされ、その他のロールは変更されません：ログインのたびに動的アクセスマッピングが使用されますが、アクセスマッピング構成にリストされていないロールは更新されません。定義されたアクセスマッピングルールにリストされているグローバルロール、デフォルトアプリケーション、デバイスグループのみが上書きされます。
以下のルールで選択されたロールは、ログインのたびにユーザーに再割り当てされ、その他のロールはクリアされます：デフォルトです。動的アクセスマッピングではユーザーのログインごとに、トークンに基づいてユーザーのロールが割り当てられます。Things Cloud 内のユーザーロールは、次回のユーザーログイン時に上書きされるため、変更することはできません。この動作を変更するには、残りのオプションのいずれかを選択します。

上記の最初の 2 つのオプションのいずれかを選択した場合、管理者はユーザー管理で SSO ユーザーのロールを編集できるようになります。詳細については、権限の管理を参照してください。

動的アクセスマッピングの構成では、JWT クレームに基づいてユーザーにロールを割り当てるルールを定義できます。トークンの値に一致するルールを使用して、適切なロールセットがユーザーに割り当てられます。

カスタムアクセスマッピング-1 カスタムアクセスマッピング-2

上記の例でユーザーがログインしようとすると、デコードされた JWT クレームは次のようになります。

{
...
"user": "john.wick",
...
}

このユーザーには、「region north」という名前のデバイスグループに対して、グローバルロール「ビジネスユーザー」、デフォルトアプリケーション「コックピット」、インベントリロール「Manager」および「リーダー」へのアクセス権が付与されます。

ユーザートークンに一致するアクセスマッピングがない場合、ユーザーはログインしようとすると「アクセスが拒否されました」というメッセージが表示されます。これは、アクセスマッピングが定義されていないため、すべてのユーザーが SSO を使用してログインできなくなった場合にも発生します。

新しいルールを追加するには、下部にある アクセスマッピングを追加 または インベントリロールのマッピングの追加 をクリックします。アクセスマッピングのステートメントは、次の図のように複数のチェックで構成されます。および をクリックすると、既存のステートメントにルールを追加できます。ルールを削除するには、削除アイコンをクリックします。

新しいロールは、一致するすべてのアクセスマッピングからユーザーに追加されます。1 つのアクセスマッピングステートメントがロール「管理ユーザー」を割り当て、2 つ目のアクセスマッピングステートメントがロール「ビジネスユーザー」を割り当て、両方が定義された条件を満たしている場合、ユーザーにはグローバルロール「ビジネスユーザー」および「管理ユーザー」へのアクセスが許可されます。

演算子として"=“を使用する場合、値フィールドでワイルドカードを使用できます。サポートされているワイルドカードはアスタリスク（*）で、０個以上の文字に一致します。例えば、「cur*」と入力すると「cur」、「curiosity」、「cursor」など、「cur」で始まるものと一致します。「f*n」は「fn」、「fission」、「falcon」など、「f」で始まり、「n」で終わるものすべてに一致します。

アスタリスク文字を厳密に一致させる必要がある場合は、バックスラッシュ（\）を追加してエスケープする必要があります。例えば、文字列「Lorem*ipsum」と正確に一致するには、値は「Lorem\*ipsum」である必要があります。

カスタムアクセスマッピング

この場合、次のクレームが条件に一致します。

{
 ...
 "user": {
    "type": "human"
 },
 "role": [
    "ADMIN"
 ],
 ...
}

ユーザーのログイン時に、名、姓、E メール、電話番号などのユーザーデータも JWT クレームから取得できます。管理者は、ユーザーデータマッピングのソース ラジオボタンを使用して、値をアクセストークンまたはIDトークンから取得するかどうかを決定できます。

それに基づいて、ユーザーデータマッピングが構成できます。

ユーザーデータマッピング

各フィールドは、JWTからデータを取得するために使用されるクレーム名を表しています。ユーザーデータマッピング構成は任意であり、管理者は必要なフィールドのみを使用できます。構成が空であるか、クレーム名が JWT トークンで見つからない場合、ユーザーデータの値は空として設定されます。

エイリアスのマッピングは、SSOログインのコンテキストでは使用されないため、利用できません。

ユーザー名のクレーム名は、ユーザー ID 構成ウィンドウで構成できます。ユーザーIDは、ログインプロセス中に認可サーバーからプラットフォームに送信される認証トークンペイロードの任意のトップレベルフィールドに設定できます。監査ログ内の認証トークンを検査して、正しいフィールドが使用されていることを確認することをお勧めします（トラブルシューティング参照）。

定数値を使用 チェックボックスが選択されている場合、SSO 経由で Things Cloud プラットフォームにログインするすべてのユーザーに１つのユーザー ID が使用されます。これは、SSO 経由でログインするすべてのユーザーが、Things Cloud プラットフォームで同じユーザーアカウントを共有することを意味します。このオプションの使用は推奨されません。

各トークンは、サイニング証明書によって署名されます。現在、サイニング証明書を構成するには次のオプションがあります。

Azure AD 証明書検出アドレスを指定します。

署名検証 Azure

ADFS マニフェストアドレスを指定します（ADFS 3.0 の場合）。

署名検証 ADFS

証明書の公開キーを手動で Things Cloud に提供します。証明書の定義には、アルゴリズム情報、公開キーの値、有効期間が必要です。

署名検証カスタム

JWKS（JSON Web Key Set）URIを指定します。JWKSは、認可サーバーによって発行されたトークンを検証するために使用される公開キーを含むJWKオブジェクトのセットです。

署名検証 JWKS

備考

Things Cloudは、(n、e) パラメーターペアまたは「x5c」証明書チェーンとして、RSA キーを含む証明書のみをサポートします。他のキータイプ（楕円曲線など）はサポートされていません。

プレースホルダー

一部のフィールド内では、実行時に Things Cloud によって解決されるプレースホルダーを使用できます。利用可能なプレースホルダーは、次の通りです。

プレースホルダー	説明
clientId	クライアント ID フィールドの値
redirectUri	リダイレクト URI フィールドの値
code	認証リクエストに応じて認可サーバーによって返されたコード
refreshToken	トークンリクエスト後に認可サーバーから返されたリフレッシュトークン

これらのプレースホルダーは、次のフィールドの認証リクエスト、トークンリクエスト、リフレッシュリクエスト、ログアウトリクエストで使用できます。

URL
Body
Headers
Request parameters

フィールド内でプレースホルダーを使用するには、ドル記号を先頭に付けた２つの中括弧内にプレースホルダーを置きます。

プレースホルダーは、テキストの一部として使用することもできます。

備考

プレースホルダーが正しいかどうかは検証されません。認識されないプレースホルダーやスペルが間違っているプレースホルダーは、処理されずにテキスト内に残されます。

Azure AD 統合

この統合は、OAuth2 と OpenID Connect を使用して Azure AD との統合が正常に検証されました（SAMLはサポートされていません）。構成手順は https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code で参照できます。

次の手順は、Things Cloudで SSO に Azure AD（Azure Active Directory）を使用する方法を示しています。

必要条件

Azure ADへの管理アクセスが必要です。

Azure AD の構成

Things Cloud を Azure AD に接続するには、Azure AD でアプリ登録を作成する必要があります。

左側の管理の下にある アプリの登録 を選択し、上部にある 新規登録 をクリックします。
表示されたウィンドウで、新しいアプリ登録の名前を入力します。
リダイレクト URI タイプ として「Web」を選択し、テナントのOAuthエンドポイントへのURL（例：「https://documentation.cumulocity.com/tenant/oauth」）を入力します。この値は、Things Cloudテナントからのものです。管理 > 設定 > 認証 > シングルサインオン に移動します。リダイレクト URL は次の通りです。プラットフォームによって事前に入力されます。Things Cloud の SSO 設定で Redirect to the user interface application が有効になっている場合、任意で「https://<tenant_domain>/apps/*」などを設定します。
登録をクリックして、アプリ登録を作成します。

アプリ登録の詳細ページの概要には、アプリケーション（クライアント）ID やディレクトリ（テナント）ID（Things Cloud のテナント用）など、後で必要になるいくつかの ID とエンドポイントが含まれています。

アプリ登録の概要

さらに、アプリの登録には、Things Cloud が認証に使用するシークレットが必要です。

アプリ登録の詳細ページで、左側の管理の下にある 証明書とシークレット をクリックします。
新しいクライアント　シークレット を選択します。
説明を入力し、有効期限を選択します。
追加をクリックしてシークレットを追加します。

注意

新しいシークレットの値を別の場所にコピーします。ページを離れると表示されなくなります。
シークレット文字列には「=」文字を含めないでください。これは、後でURLで使用する場合と競合する可能性があります。存在する場合は、新しいものを作成します。

必要に応じて、Things Cloud で使用するユーザーを Azure AD に作成します。

Things Cloud での Azure AD の SSO 構成

管理アプリケーションで 設定 > 認証 に移動し、シングルサインオン タブに切り替えます。

GETリクエストにより関連情報を取得します。以下のリンクには頭に"https://“を付けるようにしてください。

login.microsoftonline.com/<Directory tenant ID>/.well-known/openid-configuration

レスポンスは次のようになります。

{
    "token_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/oauth2/token",
    "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys",
    "response_modes_supported": [
        "query",
        "fragment",
        "form_post"
    ],
    "subject_types_supported": [
        "pairwise"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ],
    "response_types_supported": [
        "code",
        "id_token",
        "code id_token",
        "token id_token",
        "token"
    ],
    "scopes_supported": [
        "openid"
    ],
    "issuer": "https://sts.windows.net/4d17551b-e234-4e18-9593-3fe717102dfa/",
    "microsoft_multi_refresh_token": true,
    "authorization_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/oauth2/authorize",
    "device_authorization_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/oauth2/devicecode",
    "http_logout_supported": true,
    "frontchannel_logout_supported": true,
    "end_session_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/oauth2/logout",
    "claims_supported": [
        "sub",
        "iss",
        "cloud_instance_name",
        "cloud_instance_host_name",
        "cloud_graph_host_name",
        "msgraph_host",
        "aud",
        "exp",
        "iat",
        "auth_time",
        "acr",
        "amr",
        "nonce",
        "email",
        "given_name",
        "family_name",
        "nickname"
    ],
    "check_session_iframe": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/oauth2/checksession",
    "userinfo_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/openid/userinfo",
    "kerberos_endpoint": "https://login.microsoftonline.com/4d17551b-e234-4e18-9593-3fe717102dfa/kerberos",
    "tenant_region_scope": "EU",
    "cloud_instance_name": "microsoftonline.com",
    "cloud_graph_host_name": "graph.windows.net",
    "msgraph_host": "graph.microsoft.com",
    "rbac_url": "https://pas.windows.net"
}

次に、構成に次の値を入力します。

Azure	Things Cloud	値
ログインURL; OpenID構成; トークンエンドポイントの始まり	Azure AD アドレス	Azure ADテナントのアドレス（例:「https://login.microsoftonline.com」）
ホーム > 概要 > プライマリドメイン	テナント	<ディレクトリ名>.onmicrosoft.com（例:「admtest.onmicrosoft.com」）
OpenID構成「発行者」	トークン発行者	HTTP アドレス形式のトークン発行者の値：「https://sts.windows.net/<Directory tenant ID>/」。これは末尾のスラッシュがないと機能しないことに注意してください。
アプリ登録 > <app> > アプリケーション（クライアント）ID	アプリケーションID	たとえば「7fd1ed48-f4b6-4362-b0af-2b753bb1af2b」
リダイレクトURI		Things Cloudテナントのアドレス。末尾に「/tenant/oauth」が付きます。`Redirect to the user interface application` が有効な場合、任意で「/apps/*」が付きます。
アプリ登録 - <app> > 証明書とシークレット > 値	クライアントシークレット	Azure ADクライアントシークレット（例：「hE68Q~uC1.BlSzGJSDC3_UEFvvyIZvRcCxbvV345」）
OpenID 構成元	公開キー検出 URL	「https://login.microsoftonline.com/common/discovery/keys」または「https://login.microsoftonline.com/<ディレクトリテナントID>/discovery/keys」

任意で、シングルログアウトを構成できます。

フィールド	説明
ログアウト後のリダイレクト	ログアウト後にユーザーを認可サーバーのログアウトエンドポイントにリダイレクトすることにより、シングルログアウトをアクティブ化します。
リダイレクトURL	認可サーバーから正常にログアウトした後にユーザーをリダイレクトするアドレス

Things Cloudで SSO を構成した後、ログインを試行できます。このユーザーにまだアクセスマッピングがない場合、「アクセスが拒否されました」エラーが表示される可能性があります。ただし、監査ログ（管理 > アカウント > 監視ログ）に「ユーザーログイン」イベントとJSON Webトークンが表示されるはずです。

内容は次のようになります。

{
    "typ": "JWT",
    "alg": "RS256",
    "x5t": "2ZQpJ3UpbjAYXYGaXEJl8lV0TOI",
    "kid": "2ZQpJ3UpbjAYXYGaXEJl8lV0TOI"
} {
    "aud": "7fd1ed48-f4b6-4362-b0af-2b753bb1af2b",
    "iss": "https://sts.windows.net/4d17551b-e234-4e18-9593-3fe717102dfa/",
    "iat": 1660815959,
    "nbf": 1660815959,
    "exp": 1660820080,
    "acr": "1",
    "aio": "ASQA2/8TAAAAg0xPUeu6HKAlgK3vZJsW8TdejlNB3BGSz4XFmJLzPt0=",
    "amr": [
        "pwd"
    ],
    "appid": "7fd1ed48-f4b6-4362-b0af-2b753bb1af2b",
    "appidacr": "1",
    "family_name": "Doe",
    "given_name": "Jane",
    "ipaddr": "51.116.186.93",
    "name": "Jane Doe",
    "oid": "afbff765-592e-4ae1-9334-b968dad59c84",
    "rh": "0.AXkAG1UXTTTiGE6Vkz_nFxAt-kjt0X-29GJDsK8rdTuxryuUAAw.",
    "scp": "openid User.Read User.Read.All User.ReadBasic.All",
    "sub": "zRTnTukAjU11ME1aqiPMOdwk9jVNmInXbeuoUr_3cYk",
    "tid": "4d17551b-e234-4e18-9593-3fe717102dfa",
    "unique_name": "jane@admtest.onmicrosoft.com",
    "upn": "jane@admtest.onmicrosoft.com",
    "uti": "IcTqpKPIA0G_P1Lyw6xBAA",
    "ver": "1.0"
} [
    256 crypto bytes
]

カスタムテンプレート構成のセクションにある説明と同様の方法でクレームを使用してユーザー属性をマップし、アクセス許可を付与できるようになりました。

認可サーバーからのアクセストークンの使用

認可サーバーからの OAuth2 アクセストークンの使用を Things Cloud に直接リクエストできます。これにより、アプリケーションまたはユーザーは、プラットフォームにログインしたり、Basic 認証を使用したりすることなく、リソースにアクセスできます。これは、認可サーバーを利用してアプリケーションのアクセストークンを取得し、後続のリクエストで Things Cloud に送信できるようになります。

必要条件

この機能には、一般的な要件に加えて次のものが必要です。

認可サーバーは、OAuth2 クライアント資格情報付与タイプをサポートする必要があります。
すべてのマイクロサービスは、Microservice Java SDK バージョン 1018.6.0 以降で構築されています。カスタムビルドのマイクロサービスについては、セキュリティを参照してください。

認可サーバーからのアクセストークンを使用するように認証を構成する

外部トークン構成 セクションで、この認証オプションを有効または無効にします。外部トークンの無効

この認証が有効な場合、標準的な JWTトークン認証よりも優先されます。例えば、Authorization: Bearer {{access token}} ヘッダーを持つ Things Cloud への HTTP リクエストは、アクセストークンのソースが Things Cloud によって発行されたトークンではなく、あなたの認可サーバーであると仮定します。ユーザー ID またはアプリケーション ID をアクセストークンのトップレベルクレームに設定します。

外部トークンユーザーID

Things Cloud は、構成されたユーザー ID またはアプリケーション ID が割り当てられるユーザーを作成します。さらに、このユーザーには アクセスマッピング セクションで定義されたアプリケーションにアクセスするためのロールが付与されます。

備考

これが設定されている場合、アプリケーションを代表する Things Cloud ユーザー（アクセストークンは クライアント資格情報フロー で取得されます）、または認可サーバーのユーザー（アクセストークンは パスワード付与タイプ で取得されます）を作成できます。

デフォルトでは Things Cloud は、トークンの有効期限が切れていないこと、およびその署名が以前に構成した署名と一致することを検証します。必要な認証情報を使用して、イントロスペクションまたはユーザー情報検証を構成することで、トークンの検証を強化できます。このようにして、プラットフォームはアクセストークンが意図的に無効化されたか期限切れになったかどうかを認識します。無効なアクセストークンでは、Things Cloud リソースにアクセスできません。

イントロスペクションエンドポイント

Things Cloud は、トークンイントロスペクションを使用して、アプリケーションのアクセストークンの有効性を検証します。一般に、このエンドポイントは、クライアント資格情報フローまたはその他の OAuth2 フローを介して取得されたアクセストークンに使用できます。

イントロスペクションを構成するには、イントロスペクションエンドポイントと、アクセストークン、クライアント ID、クライアントシークレット、および「Authorization」リクエストヘッダーを含む URL エンコード (x-form-urlencoded) 本文を指定します。Things Cloud は、認可サーバーのイントロスペクションエンドポイントにアクセストークンのステータスを照会するようリクエストします。トークンがアクティブな場合は、トークンの署名の検証に進みます。

外部トークンイントロスペクション検証

アクセストークン検証頻度 を構成して、イントロスペクションを実行する頻度を設定できます。同じアクセストークンを取得するために、常に認可サーバーを呼び出すのはコストがかかる可能性があるためです。トークンの検証ステータスは、指定された期間、内部的にキャッシュされます。その間にトークンが取り消された場合、Things Cloudは次の検証中にのみ認識します。つまり、トークンは次の検証まで引き続き考慮されます。これを回避するには頻度を使用します。デフォルト値は 1 分です。

外部トークン検証間隔

ユーザー情報エンドポイント

ユーザー情報リクエストは、ユーザーのアクセストークンの有効性を確認するためにも使用できます。イントロスペクションとは異なり、ユーザー情報リクエストにはユーザーコンテキストが必要です。これは、クライアント資格情報フローで取得したアクセストークンを検証するためには使用できないことを意味します。

外部トークンユーザー情報検証

注意

2 つの検証方法のいずれかを使用する場合、認可サーバーがイントロスペクションまたはユーザー情報エンドポイントを公開していることを確認してください。

Keycloak 統合

グローバルログアウト機能（Keycloak バージョン 12.0.0 以降で利用可能）

Keycloakとの統合により、管理者は OpenId Connect に基づくグローバルログアウト機能を使用できるようになります。Keycloak認可サーバーからのイベントは、ログインプロセスで使用されるトークンと同じ方法で検証されるログアウトトークンとともに、すべてのアプリケーション（Things Cloudプラットフォームを含む）に送信されます。この機能を使用すると、特定のユーザーのアプリケーションとKeycloakの両方でセッションを終了できます。

グローバルログアウト機能を設定するには、次の手順に従います。

管理者コンソールに移動します。
テナントの SSO 構成で使用されるレルムを選択します。
構成セクションの クライアント に移動します。
SSO 構成で使用するクライアントを選択します。
バックチャンネルログアウト URL フィールドに「https://mytenant.je1.thingscloud.ntt.com/user/logout/oidc」を設定します。

グローバルログアウト機能を使用するには、次の手順に従います。

管理者コンソールに移動します。
テナントの SSO 構成で使用されるレルムを選択します。
管理セクションのユーザーに移動します。
特定のユーザーを選択します。
管理セクションのセッション タブに移動し、ログアウト をクリックします。

すべてのユーザーのログアウト機能

Keycloak はまた、管理者がすべての SSO ユーザーをログアウトできる機能も提供します。

すべてのユーザーのログアウト機能を設定するには、次の手順に従います。

管理者コンソールに移動します。
テナントの SSO 構成で使用されるレルムを選択します。
構成セクションのクライアントに移動します。
SSO 構成で使用するクライアントを選択します。
管理URL を “https://mytenant.je1.thingscloud.ntt.com/user/keycloak” に設定します。

すべてのユーザーのログアウト機能を使用するには、次の手順に従います。

管理者コンソールに移動します。
テナントの SSO 構成で使用されるレルムを選択します。
管理セクションのセッション タブに移動し、すべてログアウト をクリックします。

すべてのユーザーのログアウトイベントは、1 つのKeycloak レルムのスコープ内でのみ実行されることに注意してください。さらに、SSO 機能の構成として使用されているクライアントに正しい 管理URL 値があるテナントに対してのみ送信されます。

セッションタブで、Keycloak管理者は、それぞれのクライアントに存在するアクティブなセッションの数を確認し、ログアウトイベントによって影響を受けるテナントとユーザーの数を見積もることもできます。

すべてのユーザーのログアウトイベントがテナントによって受信されたか、単一ユーザーのログアウトイベントが受信されたかを確認するために、Things Cloud 管理者は監査ログにログアウトイベントに関する情報があるかどうかを確認できます。監査ログは、管理アプリケーションの 監査ログ タブの アカウント で利用できます。

トラブルシューティング

プラットフォームに送信された認証トークンのフィールドの一部には、上記で説明した正しい構成に必要な情報が含まれているため、その内容を検査すると特に役立ちます。

管理アプリケーションで アカウント > 監査ログ をクリックし、カテゴリ「シングルサインオン」でフィルターし、エントリ「Json web token claims」を探します。

トークンのコンテキストは JSON 形式で表示されます。

監査トークンの内容

はじめに

構成設定

構成アクセス

構成ビュー

カスタムテンプレート構成

接続の構成方法

プレースホルダー

Azure AD 統合

Azure AD の構成

Things Cloud での Azure AD の SSO 構成

認可サーバーからのアクセス トークンの使用

認可サーバーからのアクセストークンを使用するように認証を構成する

イントロスペクション エンドポイント

ユーザー情報エンドポイント

Keycloak 統合

グローバル ログアウト機能（Keycloak バージョン 12.0.0 以降で利用可能）

すべてのユーザーのログアウト機能

トラブルシューティング

認可サーバーからのアクセストークンの使用

イントロスペクションエンドポイント

グローバルログアウト機能（Keycloak バージョン 12.0.0 以降で利用可能）