Oktaコネクターに関するガイダンス

フローでOktaコネクターを使用する際のガイダンスとベストプラクティスについては、次の情報をお読みください。

認証

コネクターを承認するには:

  • Okta Workflows OAuthアプリに割り当てられている必要があります。
  • スーパー管理者資格情報を持っている必要があります。

コネクターの初期承認に加え、この接続の再承認にはスーパー管理者権限を持つアカウントが必要です。

Oktaアカウントの承認には次の情報も必要です。

  • Domain(ドメイン)Okta orgのドメイン。たとえば、Okta orgのURLがhttps://yourcompany.okta.comであれば、ドメインはyourcompany.okta.comです。
  • [Client ID(クライアントID)][Client Secret(クライアントシークレット)]Okta Workflows OAuthアプリのクライアントIDとクライアントシークレット。これらの値を特定するには、Okta Admin Console[Applications(アプリケーション)][Okta Workflows OAuth][Sign On tab(サインオンタブ)][Sign On Methods(サインオン方式)]に移動します。

アカウントのタイプ

接続の作成に使用されるアカウントには、スーパー管理者の資格情報が含まれている必要があります。

多くの場合は、Okta Workflowsのスーパー管理者資格情報を使って特定のサービスアカウントを作成し、そのアカウントを使って接続を承認することをお勧めします。それ以外の場合、接続のセットアップに使われるOktaユーザーアカウントは、Okta Workflowsによって実行されるすべてのアクションと関連付けられます。

新しい機能とスコープ

Okta Workflowsのリリースによって機能が追加される、またはorgで機能が有効化されると、これらの更新によってOkta Workflows OAuthアプリで利用できるスコープにスコープが追加される場合があります。

新しいスコープを提供する機能がリリースまたは有効化されたら、「サポートされるスコープ」セクションに記載されている手順に従ってください。

サポートされるスコープ

Okta Workflows OAuthアプリにスコープを付与するには、Workflowsコンソールで次の手順を実行します。

  1. [Applications(アプリケーション)] [Okta Workflows OAuth] [Okta API Scopes(Okta APIスコープ)]に移動します。利用できるスコープのリストが表示されます。
  2. 付与するスコープごとに[Grant(付与)]をクリックします。Okta Workflows OAuthアプリにスコープが表示されないときは、Grant consent to scope(スコープに同意を付与)APIエンドポイントを使って手動でスコープを付与できます。

既存の接続にスコープを追加するときは、接続を再認証する必要があります。

利用できるスコープのリスト

アスタリスク(*)が付いているスコープは自動的に付与されます。Okta Workflows OAuthアプリを使用して付与する必要はありません。

  • openid*
  • profile*
  • email*
  • phone*
  • address*
  • groups*
  • offline_access*
  • okta.apps.manage
  • okta.apps.read
  • okta.clients.manage
  • okta.clients.read
  • okta.clients.register
  • okta.deviceAssurance.manage
  • okta.deviceAssurance.read
  • okta.devices.manage
  • okta.devices.read
  • okta.eventHooks.manage
  • okta.eventHooks.read
  • okta.events.read
  • okta.factors.manage
  • okta.factors.read
  • okta.governance.accessCertifications.manage
  • okta.governance.accessCertifications.read
  • okta.governance.accessRequests.manage
  • okta.governance.accessRequests.read
  • okta.governance.entitlements.manage
  • okta.governance.entitlements.read
  • okta.groups.manage
  • okta.groups.read
  • okta.identitySources.manage
  • okta.identitySources.read
  • okta.idps.manage
  • okta.idps.read
  • okta.inlineHooks.manage
  • okta.inlineHooks.read
  • okta.linkedObjects.manage
  • okta.linkedObjects.read
  • okta.logs.read
  • okta.networkZones.manage
  • okta.networkZones.read
  • okta.policies.manage
  • okta.policies.read
  • okta.roles.manage
  • okta.roles.read
  • okta.schemas.manage
  • okta.schemas.read
  • okta.trustedOrigins.manage
  • okta.trustedOrigins.read
  • okta.users.manage
  • okta.users.read

限定早期アクセスリリース

  • okta.workflows.invoke.manage

ベストプラクティス

次に、Oktaカードの追加の構成情報を示します。

[システムログを検索]のオプション

  • [Keyword(キーワード)]フィールドで、クエリパラメーターqは、ログイベントオブジェクトの属性値に対してキーワードマッチングを実行するために使用されます。すべての入力キーワードは正確に一致する必要があります(キーワードマッチングでは大文字と小文字が区別されます)。「システムログ」を参照してください。
  • null値が含まれる属性に対してキーワードマッチングを使用した場合、値は返されません。
  • eq演算子を使用してキーと値の各ペアを連結してから、and演算子を使用して各種のキーを結合します。その他の演算子を使用するには、[Custom Filter(カスタムフィルター)]フィールドを使用して独自の式を構築します。それらの事前定義されたフィールドと[Custom Filter(カスタムフィルター)]フィールドは、and演算子で連結します。「システムログ」を参照してください。

ユーザーまたはグループの取得

次の例は、最初の200グループとストリーミングレコードの両方を取得するための構成を示しています。

最初の200レコード

このフローは、ユーザーが参加した、月次ベースで最初の200グループを取得します。

  • 親フロー

  • ヘルパーフロー

ストリーミングレコード

このフローは、特定のユーザーが参加したすべてのグループの1つの[カスタムフィールド]値を更新します。

  • 親フロー

  • ヘルパーフロー

関連項目

Oktaコネクター

Workflows要素

Oktaコネクターに関するガイダンス

Okta APIドキュメント