SSOとプロビがセットである必要はないんだ

OktaのOINアプリを触っていると「もうちょっと融通きけばなー」って思うことがあるんですよね。
「SAMLアサーションのマッピング変えたい」とか、
「ユーザによってプロビジョニングのマッピング変えたい」とか。

そういった場合には、SSOとプロビジョニングでアプリケーションを分けてみるのも手ですよとお伝えする記事です。
※個人的に技術的な問題はないだろうと感じている方法です。アプリケーションに関しては後述の課題もありますのでご注意を

そもそもの背景

Okta触ったことのある人ならみなさん理解されているとは思いますが、OktaやSAMLの仕様によって以下のような共通認識があります。

• OktaからのプロビジョニングはOINアプリを使う必要がある

• アプリにアサインしたユーザがSSO・プロビジョニングの対象となる

• 1つのIdpとしか認証連携できないSaaSが多い

その結果１つのSaaSに対し１つのアプリケーションをOkta上で作成し、SSOもプロビジョニングも行っている場合が多いです。
別に間違っていません。非常にシンプルな構成で保守もしやすいです。

ただ、Office365のようにサブドメインごとにアプリケーションを作ったりするものや、boxのようにユーザによって作成する個人フォルダの設定変えたいなんて要望もあったりします。
他にも、特定SaaSに認証連携はさせたいけど、一部の既存ユーザはプロビジョニングさせたくないとかね。

そんな時はどうするか

SSOとプロビジョニングのアプリケーションを、SSO専用とプロビジョニング専用の２つに分けちゃえばいいんです。
SSOとプロビジョニングはそれぞれ異なる方式で動いているので技術的には分けてしまっても問題ないと私は思っています（個人の感想です）

ユーザのアサインは２つのアプリにしなくてはいけませんが、同じにしたければ、同じグループをアサインしておけば運用時の手間は増えません。

Office365のプロビジョニングは……

私はドメインごとにOktaにOffice365アプリ作っていまして（これには理由があるのですが）、各アプリケーションごとにプロビジョニングの設定するのが嫌でした。結果、以下のような構成にしています。
・Office365のプロビジョニング用アプリ：１（Office365利用する全員をアサイン）
・Office365の認証連携用アプリ：複数（ドメインごとのユーザグループをアサイン）

ドメイン増えるごとにプロビジョニングでドキドキしなくてよくなるのがメリットです。マッピングルールを複数にしたい場合はプロビジョニング用アプリケーションを増やします。
マッピングルールが多くなりすぎる場合は、SSOとプロビはセットの方がいいかもしれません。

ただし、Office365に関してはImmutableIDの関係上プロビジョニングが先に動くよう制御するとか、ImmutableIDの値が決め打ちとなるような工夫が必要です。ADがソースの人はあんまり考えなくても大丈夫です。

boxのプロビジョニングは……

Oktaのboxプロビジョニングは個人フォルダの自動生成や、個人フォルダの所有者に管理者を指定することができます。
できるんですが、実際の運用だと複数の管理者を設定して、管理者一人当たりの負荷を減らしたいって会社さんもいるみたいですね。
ただし、boxは１つのIdpとしか認証連携できません。

そういう場合にはプロビジョニング用のboxアプリケーションを複数準備して、それぞれ別の管理者でAPIの認証をすると、個人フォルダの所有者を複数の管理者で分散させることができます。

ただし、boxはプロビジョニングする時としない時で、アプリケーションの挙動がちょっと違っていたりするので、こちらも注意が必要です。Username変えた時の挙動とかね。

最後に

今回の記事は無闇矢鱈にOkta上のアプリケーションを増やすことを目的とした記事ではないです。増やすことで柔軟な構成が取れるようになる反面、管理工数や設計難度、検証や挙動差異によるリスクもあります。

組織特有の使い方があるとか、プロビジョニングしているアプリのSAMLアサーションの値を標準から変えないといけないとか、プロビジョニングと認証連携のアプリケーションを分けた方が低リスクな構成になるとか
そういったことがある場合に、この記事が何かの「気づき」になればいいなと思います。