インストールおよびアップグレード > ThingWorx のインストール > セキュリティコンフィギュレーション > シングルサインオン認証 > 中央認証サーバーおよび ID プロバイダとして AD FS を使用 > リソースプロバイダとしての ThingWorx の設定
リソースプロバイダとしての ThingWorx の設定
resourceServerSettings.json ファイルの設定
ThingWorx がリソースサーバーアプリケーションである場合、この手順は必須です。
1. ThingWorx サーバーを停止します。
2. sso-settings.json と同じディレクトリ内に resourceServerSettings.json ファイルを作成します。
以下は、resourceServerSettings.json ファイルの構造の例です。
{
 "ResourceServerSettings": {
	"accessTokenServicesSettings": {
		"tokenUsernameAttribute": "See information in the table below",
		"tokenPublicKeyUrl": "See information in the table below",
		"administratorAlias": "See information in the table below",
		"administratorInternalName": "Administrator",
		"issuer": "See information in the table below",
		"tokenValidationType": "local",
		"tokenClientIDAttribute": "See information in the table below"
	},
	"globalScopes": "See information in the table below",
	"scopeClaimName: "See information in the table below",
	"uriScopes": [
	{
		"uri": "See information in the table below",
		"scopes": "See information in the table below",
		"method": "See information in the table below"
	}
 ]
}
3. 要件に合わせて各パラメータの値を編集するようにしてください。実装は、組織のセキュリティポリシー、フェデレーションの CAS など、いくつかの要因によって異なる場合があります。次の表に示す情報をガイダンスとして使用して、さまざまなパラメータの値を設定します。
4. ThingWorx サーバーを起動します。
ResourceServerSettings.accessTokenServicesSettings の設定
パラメータ
説明
値
tokenUsernameAttribute
オプション: リソースリクエストのユーザー名を格納するクレーム名。
デフォルト値: “unique_name”
tokenPublicKeyUrl
必須: AD FS 公開キーエンドポイント (アクセストークンの検証に使用)。
値は次のように構成されます。
https://<ADFS ホスト FQDN>adfs/discovery/keys
administratorAlias
オプション。
ThingWorx 管理者として RP にアクセスする場合にのみ必須です。
* 
sso-settings.json ファイルですでに設定されている場合、ここで値を設定する必要はありません。
AD FS で設定されている管理者のユーザー名。
administratorInternalName
オプション: ThingWorx で設定されている管理者のユーザー名。
Administrator
tokenValidationType
必須: アクセストークン (JWT) の検証がローカルで実行されるプロパティポイント。
local
issuer
オプション: 追加のトークン検証チェック用の Issuer 値。
トークンの ISS クレームに表示される Issuer 値。
tokenClientIDAttribute
M2M (クライアント資格証明) フローに必要です。リソースリクエスト用の SP clientID を格納するクレーム名。
* 
OAuth (M2M) AccessToken を承認するには、SP ClientID 値の名前を持つ疑似ユーザーを ThingWorx RP アプリケーションで作成する必要があります。
appid
ResourceServerSettings.globalScopes の設定
パラメータ
説明
値
globalScopes
グローバルスコープのコンマ区切りリスト。リソースにアクセスするには、これらのうち少なくとも 1 つが accessToken に含まれている必要があります。このパラメータが欠落しているか空の場合、THINGWORX がデフォルトのグローバルスコープになります。
 
"globalScopes": "THINGWORX
"globalScopes": "THINGWORX_APP1,THINGWORX_APP2"
scopeClaimName
オプション。デフォルト値は scp です。
ResourceServerSettings.uriScopes の設定
パラメータ
説明
値
uri
URI パターン。グローバルスコープへの追加のスコープを必要とするリソースまたはリソースグループを定義します。
 
Thingworx/Things/** - control all Things
Thingworx/Things/Thing1 – control Thing1
scopes
追加のスコープのコンマ区切りリスト。リストされているすべてのスコープ (グローバルを含む) への許可を持つユーザーだけがリソースを取得できます。
method
オプション。スコープが適用される URI メソッドを定義します。
* 
method プロパティが指定されていない場合、指定されている URI はすべての HTML メソッドでそのスコープによって保護されるものと見なされます。
REST プロトコルで使用可能なすべてのメソッド (GET や POST など) を値として指定できます。
URI に定義されているスコープがある場合、グローバルスコープおよび定義されている URI スコープで、そのリソースへのアクセスが許可されなければなりません。リクエストされたリソースに適用可能な URI 規則が複数存在する場合、関連するすべてのスコープでそのリソースへのアクセスが許可されなければなりません。制限されているリソースへのアクセスを防止するため、これらの REST エンドポイントに、認証サーバーに存在しない URI スコープを追加します。ThingWorx には、スコープ保護に加え、スコープとともに適用される独自のユーザーベースのアクセス許可があります。たとえば、ユーザー A が正しいスコープでリソースをリクエストしたがアクセス許可がない場合、そのリクエストは 403 エラーで失敗します。
ファイルの例
これは役に立ちましたか?