Okta Universal Directoryカスタムユーザータイプに関する既知の問題

Okta Universal Directoryカスタムユーザータイプには既知の問題があります。

新たにインポートされるユーザーのタイプは、デフォルトのOktaユーザータイプに限定されます。
User type（ユーザータイプ）（変数名userType）はOktaベーススキーマの31個の属性のうちの1つです。User type（ユーザータイプ）属性はカスタムユーザータイプの機能とは無関係です。
属性名は同じだがデータタイプが異なる2つの異なるユーザータイプを持つことはできません。データタイプは一致させる必要があります。
インポート時およびアウトバウンドプロビジョニング時に、アプリケーションのサインインページに設定されているデフォルトのOktaユーザータイプマッピングのみが更新されます。カスタムユーザータイプを使用している場合、アプリケーションに関連付けられているユーザー名は更新されません。
orgでセルフサービス登録が有効化されている場合、org内のすべてのユーザーのログインIDは、各自のメールアドレスに合わせて強制的にマッピングされます。強制マッピングは、そのorg内のすべての［User Types（ユーザータイプ）］に適用されます。
プロパティマッピングとは異なり、SAMLアサーションマッピングではタイプは認識されません。Oktaでは、すべてのSAMLアサーションマッピングにデフォルトのユーザータイプが使用されます。
- 承認された管理者のみが機密属性の編集を許可されるように、Oktaは各SAMLアサーションを検証します。これには、機密プロパティがデフォルトタイプと異なる可能性があるデフォルト以外のユーザータイプは含まれません。
- アサーションで使用される、デフォルト以外のタイプのユーザーにのみ存在するプロパティには、このチェックは適用されません。
- デフォルトタイプでは機密として扱われるが、デフォルト以外の一部のタイプでは機密として扱われないないプロパティも、常に機密として扱われます。
- SAMLユーザー名ELの検証時に、カスタムタイプではプロパティが別の方法で定義されるとしても、デフォルトユーザータイプでのプロパティの定義方法のみが考慮されます。
グループメンバーシップルールの検証は、デフォルトタイプに対してのみ行われます。これは、ユーザーインターフェイスで事前に設定した条件を使用する場合、またはOkta Expression Langaugeを使用する場合に生じます。いずれの場合も、デフォルトタイプでは式は無効です。たとえば、カスタムユーザータイプにのみ存在するプロパティが参照される場合、ルールを保存またはプレビューすることはできません。これは、プレビューされるユーザーがカスタムタイプである場合にも適用されます。カスタムタイプではなくデフォルトタイプにのみ存在するプロパティをルールが参照する際に、カスタムユーザーの評価（グループメンバーシップのプレビューまたは決定時）では、式はそのプロパティの値をnullとして扱います。
グループルールは、デフォルト以外のユーザータイプに対しては実行されません。
グループアプリの割り当ては、デフォルトのUser Type（ユーザータイプ）に対して検証されます。複数のユーザータイプ間で一貫しない属性が関連するGroup App（グループアプリ）の割り当ては、デフォルトのUser Type（ユーザータイプ）に対して検証されます。
Active Directoryからインポートされ、カスタムタイプの既存のOktaユーザーと部分一致するユーザーは、Oktaユーザー名の形式としてユーザープリンシパル名（UPN）のみを使用できます。メール、sAMAccountName、その他のカスタムappuserプロパティなど、管理者が別のOktaユーザー名形式を選択した場合、ログインフィールドのActive Directoryプロパティマッピングは変更されるはずですが、現時点では、デフォルトのOktaユーザータイプのマッピングのみが更新されます。
Active Directoryの設定ページでは、ユーザー向けにインポートフローの間にOktaログインを設定でき、アウトバウンドプロビジョニングフローの間にActive DirectoryuserNameを設定できます。現時点では、いずれの場合も、このユーザーインターフェイスからのマッピングでは、更新はデフォルトのOktaユーザータイプに対してのみ行われます。
LDAPの設定ページでは、ユーザー向けにインポートフローの間にOktaログインを設定し、アウトバウンドプロビジョニングフローの間にActive DirectoryuserNameを設定できます。いずれの場合も、このユーザーインターフェイスからのマッピングでは、更新はデフォルトのOktaユーザータイプでのみ行われます。
LDAPプロビジョニング設定ページのUIで、［Okta Attribute Mappings（Okta属性マッピング）］セクションは、LDAPとデフォルトのOktaユーザープロファイルの間のマッピングのみを定義します。言い換えると、このセクションでいずれかの属性マッピングが更新されると、その更新はアプリユーザープロファイルとデフォルトのOktaユーザープロファイルの間のマッピングにのみ反映されます。アプリユーザープロファイルとカスタムOktaユーザープロファイルの間のマッピングに変更を加える必要がある場合、Profile Editorで変更を行う必要があります。
プロビジョニング設定では、RDNが有効な属性であることが検証されますが、そのチェックはデフォルトのUser Type（ユーザータイプ）に対してのみ行われます。
Active Directoryインポートと同様に、LDAPインポート設定ページで管理者がOktaユーザー名の形式を変更した場合、その変更はLDAPからデフォルトのOktaユーザータイプへのマッピングにのみ適用されます。
IdPルーティングルールまたはインバウンドフェデレーションにIDプロバイダー機能を使用する場合、ユーザープロパティの解釈は、デフォルトのユーザータイプにのみ基づきます。つまり、ユーザープロパティが存在するかどうか、機密データが含まれるかどうかなどを、システムはデフォルトのユーザータイプのみに基づいて判断します。意図しない動作を回避するには、IdPポリシーで使用されるプロパティは、すべてのユーザータイプで同じ方法で構成します。
インバウンドフェデレーション向け：
- JITユーザーは、デフォルトタイプで作成されます。
- インバウンドフェデレーションのUser Match（ユーザー一致）を構成する場合、デフォルトタイプのプロパティのみがリスト表示または検証されますが、一致の試行には実際のUser Type（ユーザータイプ）が使用されます。
- マッピングは、自動的にIdPユーザーまたはアプリユーザーからデフォルトタイプに設定されますが、カスタムタイプには設定されません。したがって、マッピングを手動で作成しない限り、これらのユーザーには何もマッピングされません。
Office 365またはSharepointの新しいアプリテンプレートがOktaで検出されると、アプリの既存のインスタンスは更新されます。現時点では、これらの自動更新はデフォルトのUser Type（ユーザータイプ）と関連付けられたアプリのインスタンスでのみ行われます。Office 365またはSharepointにデフォルト以外のUser Type（ユーザータイプ）が割り当てられている場合、これらのアプリでテンプレートに加えられた変更は、これらのアプリのインスタンスには適用されません。