このブログはこちらの英語ブログの機械翻訳です。
セルフサービス登録は、Oktaのお客様にとって必要不可欠かつ一般的に使用されている機能です。Okta Classicでは、管理者設定ページのディレクトリセクションの一部としてこの機能があり、Okta organizations（orgs）では機能フラグ（SELF_SERVICE_REGISTRATION）でご利用いただけます。管理者は、Universal Directoryでプロファイルの一部として属性を作成し、それらの属性をセルフサービス登録ポリシーに追加できます。Classicフローでは、エンドユーザーが新しいアカウントにサインアップするとき、ポリシーによってフィールドが設定された登録フォームが表示されます。
Okta Identity Engine（OIE）のリリースでは、最新化と柔軟性に多くの改善が加えられました。一部の改善点には、ユーザー登録に関連付けられたエンドポイントとポリシーが含まれています。OIEでは、登録ポリシーは新しいProfile Enrollment Policyの一部ですです。これらのポリシーは、管理コンソールの [セキュリティ > プロファイル登録] にあります。プログレッシブプロファイリングは、プロファイル登録ポリシー内に組み込まれた機能で、組織またはアプリケーション内のユーザーのナビゲーションエクスペリエンスのそれぞれの段階で、既存のユーザーにさまざまな属性の入力を要求する機能を提供し、長い登録フォームの場合、ユーザーサインアップの面倒を軽減します。
OIE のプログレッシブ プロファイリングを使用したプロファイル登録は、従来のエンジンのセルフサービス登録ポリシーと互換性がありませんでした。読み取り専用/非表示タイプの属性が必須の場合、ユーザーはそれらを入力できませんでした。これは、セルフサービス登録を有効にした状態で従来のエンジンを使用しており、OIE へのアップグレードを希望する顧客にとって課題となりました。OIE はポリシーに関する要件が厳しいため、エンドユーザーが読み取り専用または非表示の属性を更新することを許可していません。従来のエンジンには、有効にすると、登録時にユーザーが読み取り専用/必須属性を柔軟に入力できる別のフィーチャーフラグもあります。
では、私たちアクセス管理チームは、お客様のためにどのようにこの問題を解決したのでしょうか？ソリューションは2段階で行われました。
- セルフサービス登録とプログレッシブプロファイリングを個別に切り替える機能を分割しました。それにより、移行されたorgsにClassicエンジンの非対応属性がある場合、管理者が Universal Directory（[ディレクトリ -> プロファイルエディタ] ）で問題のある属性を修正できるまで、プログレッシブプロファイリングは無効のままにしておくことができます。
- OIEへの移行の際、orgの非対応属性や機能フラグをチェックし、アップグレード時にそれらの属性が無視されることを示す「警告への同意」メッセージを管理者に表示するバリデーターを構築しました。管理者が警告に同意すると、管理者は移行されたセルフサービス登録を使用してOIEにアップグレードできます。
結論として、新しいSSR移行の機能強化により、多くのOkta orgs Classicのブロックが解除され、OIEにシームレスに移行してOktaをベストな状態でご利用いただけます。
このブログ投稿について質問がありますか? eng_blogs@okta.comまでお問い合わせください。
Oktaの洞察力に富んだエンジニアリングブログで、知識をさらに深めてください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください。
Oktaは、最新かつ高度なアイデンティティ管理の可能性を解き放ちます。詳細は、セールス担当者にお問い合わせください。
