はじめに

株式会社エイプリルナイツのアドベントカレンダー15日目の記事です。

クリスマスにもらったゲームソフトの思い出

アドベントカレンダーのお題なので、幼稚園～小学生の頃の記憶をどうにかして引っ張り出してきました。
一番思い出深いのは任天堂64と一緒に買ってもらったマリオストーリーでした。
クリスマス当日にいざプレイしようとしたら64の電源コードが入ってなくて泣きそうになったのも良い思い出です。

さて本題のOktaについて書いていきます。
初見でOktaの設定やカスタマイズを対応することになっても半年間トライ&エラーをすればこれくらいは分かるようになってるということを伝えられると良いなと思っています。

Oktaとは？

　Oktaという名前は聞いたことがあるが、実際にどんな製品(システム？)なのかイメージが付かない方もいるのではないでしょうか？(私もそうでした)
Oktaとは、アプリケーションにSSO(シングルサインオン)やMFA(多要素認証)等の認証機能を提供するIdP(Identify Provider)です。
　Oktaとアプリケーションが連携することによってユーザはアプリケーションにSSOすることができ、管理者はOkta上でユーザ,アプリケーション,認証ルール等を一元管理できるという仕組みです。

Oktaの構成要素

　Oktaに限らずシステムや製品の構成要素を理解することは個人的に重要だと思っています。
仕事の中で理解したOktaの構成要素について簡単に書いてみます。
(他にも構成要素があると思いますが、仕事上の要件から利用する必要がなかったりするものもあるので、一部は省略しています)

ユーザ(User): Oktaにおけるアカウントの単位、利用者1人に1ユーザを登録させるのが一般的
グループ(Group): 複数のユーザをひとまとめにした単位、特定のアプリケーションの利用者や管理者等をひとまとめにして管理するために利用する、後述する各種ポリシーではグループ単位でユーザを割り当てるのが一般的
アプリケーション(Application): Oktaと連携してSSOを提供する先となるシステムやアプリケーション、アプリケーションに関する設定としてSSO用のURL等を設定しmetadataを発行する。システム側でOktaから発行されたmetadataを登録することでシステムにSSOの機能を提供できる
Authenticator: MFAで使用する認証方法を管理する機能、パスワードや認証メール、Okta Verify等の色々な認証方法に対応しており、これらの利用規約(パスワードポリシーとか)の設定も管理できる
Authenticator Enrollment: 各ユーザグループにどのAuthenticatorを割り当てるか管理するポリシー、グループ毎にAuthenticatorを必須、任意、禁止の3パターンと設定できる、このポリシーによってOktaのログイン画面で要求される認証要素の選択肢が決定される
Authentication Policy: Oktaに登録した各アプリケーションにおいて、SSOする際にどの認証要素を必須にして、MFAにおけるどの認証要素を追加で要求するか、SSOのセッションが生きている間は再認証を要求するか等の設定を管理する。アプリケーションにSSOする際はこのポリシーとAuthenticator Enrollmentが評価されてどの認証要素を要求するかが決定される
Global Session Policy: OktaによるSSOを利用する際に、MFAを必須にしたり、セッションライフタイムを設定したりするポリシー。こちらもSSOの際に評価されて、ユーザのSSOのセッションライフタイム等を制御する
ブランド(Brand): Oktaのログイン画面や、Oktaが送信するメールのテンプレート、ドメインに関する情報等をひとまとめにした単位、初期状態でOktaのデフォルトブランドが一つ設定済みの状態になっているが、Oktaにカスタムドメインを登録する際はブランドを新規作成して各種設定を行う
カスタムメールテンプレート: Oktaが様々なイベントを検知してユーザに送信するメールのテンプレートをまとめたもの、カスタムドメインを作成すれば、これらのメールテンプレートも自由に編集できる。また、ユーザIDやSSO用のリンクなどは変数としてメールテンプレート内に埋め込むことができる。

　他にも構成要素はあるが、ユーザがOktaからSSOする場合は上記の項目が連携してSSO,MFAを実現している。

Oktaを扱っていて感じたこと

　まず何よりもドキュメントが整備されている。
グローバルに展開している製品である以上当然なのだが、公式ドキュメントがきちんと整備されていて誰でも閲覧できるように公開されているというのは初めて製品を扱う側の敷居を大幅に下げてくれる。
これのおかげで、QAサポートに問い合わせする際も公式ドキュメントを読み込んで、ここまでは理解しているという認識を相手に伝えることができるので、コミュニケーションが格段に楽になった。
今年一年を振り返るとドキュメントの重要性を痛感する。
　あとはトラブルシューティングの際もシステムログが詳細なログを出してくれるし、SSOに失敗した場合はどのポリシーによってSSOが弾かれたか等も確認できるので、かなり快適だった。
　今後Oktaの運用チームが増えた際も公式ドキュメントを読み込んでもらえばだいたいの内容は分かるはずなので、引継ぎ資料自体も公式ドキュメントに大部分を任せられれば良いなと思っている。

最後に

　自分が得た知識を基にまとめてみましたが、いかがだったでしょうか？
実際にOktaを扱っていない方から見たら何のことやらかもしれませんが、現在進行形でOktaを扱っている方々にとってこの記事が理解の助けになれば幸いです。
Oktaは公式ドキュメントが整備されておりインターネット上で公開されているので、この記事で見た内容の深堀をしたい場合はそちらも参照することをお勧めします。(日本語はさすがに機械翻訳なのか文章に若干違和感がありますが)
現代ではシステムのセキュリティのためにSSOやMFAの導入が一般的になってきていますが、それを提供するIdPを業務で扱えたことは自分にとってはかなり幸運でした。
来年もOktaに関する業務が続くはずなので、この機会を活かしてセキュリティ周りの考え方をアップデートしていきたいと思います。
そして、今年一年の業務で関わってきた全ての方々に感謝を述べてこの記事を締めたいと思います。
ここまで読んで頂きありがとうございました。