Okta User Profile Attribute Based Something

まえがき

どもです。Gzockです。
ビットキー情シスアドカレ 11日目の記事です。私の順番は早くも3回目です。
今回はちょっと楽をします。させてください。

OktaのUser Profile 機能におけるAttrbuteって使っていますか？
知らず知らずにみなさん使ってると思います。

それぞれのユーザーを作るときに指定するLast NameとかFirtstNameとか。
ああいうのがそういうのです。個人に紐づく情報管理 = Profileですね。

姓名のみならず、実際にはそういったよくある属性の他にもUser DefinedなAttributeを持たせることができます。

そして、そこから各種SSOなどにその属性を使っていくことができます。
私はこの機能がすごく好きです。その話です。

そもそもの話

• 私は情シス所属ではありません
• 普段はIoTの開発やってます
  • 2023 AWS Summit Tokyoで弊社が登壇させてもらいましたが、その中で言及しているプラットフォームを担当しています
  • その他、登壇資料を見てもらえるとどんなヤツか大体わかると思います
    • ビットキーのIoT基盤におけるAWS IoT Rule Action活用
    • Okta Workflowsによるノーコード業務改善
    • たまにはオンプレもいいぞ？GKEとArmadillo IoTで実現するハイブリッドクラウド
    • Datadog Agent on CloudRunによるGCPトレーサビリティの向上
• なのになんで情シスアドベントカレンダーに参加してるのって？
• わかりません, ボス(@h_r_w_t_r)に聞いてください
  • ちょっとした経緯は上述のOkta WFsの記事で言及しています

この記事は何？

• Okta User Profile Attributeを使った Attribute Based なんちゃらのケースを紹介
• User Profileをうまく使うと、 グループの自動管理やSSO先でのアクセスコントロールに有用
• グループをSSO先にプロビジョニングしてそれを使った認可をやったりするときには、Okta内部でAttributeを使った自動的なグルーピングは大活躍
• あるいは一部のSaaSであれば、そもそもAttribute Based AccessControlが可能であるため、それらはOktaのProfile Attributeをそのまま連携することでシームレスに認可につなげていくことが可能
• 弊社における様々なSaaSにAttribute Basedな連携手法による柔軟な認証認可処理について諸々ご紹介！

Okta User Profileとは？

User Profile とは、Okta Universal Directoryに保存されるユーザー固有データの集合体のこと。ユーザーのメールアドレスや名前、電話番号、役職、など、デフォルトでは31の基本属性を持つ。

• https://help.okta.com/oie/ja-jp/content/topics/users-groups-profiles/usgp-about-profiles.htm

デフォルト属性をそのまま利用しても良い。もちろん使わなくても良し。

他にも任意のユーザー属性を含むこともでき、もちろんそれらもOktaにマネージドで管理してもらえる。

こうすることで自社のドメイン知識の寄った固有の追加情報をユーザーに持たせられる。

• 例) このプロダクト開発に関わっている、とか、XXというジョブを持つ、とか、こういうスキルセットを持っている、とか。

これらの”属性” = AttributeをOktaの中で応用することで、Oktaはさらにもっと便利になる可能性を秘めている。

そういったAttributeを使った何某を今回は言及していきたい。

だから、 “Okta User Profile Attribute Based Something”

参考

• プロファイルと属性を使用した操作 | Okta
• プロファイルを管理する | Okta
• カスタム属性をOktaユーザープロファイルに追加 | Okta
• ユーザーに属性の編集を許可する | Okta
• User Profiles | Okta Developer

参考程度に弊社かつ私自身のProfileをどうぞ。
ちなみに試行錯誤の結果、死に体Attributeが残っているので見ないふりをしてくださいまし。
これらの属性すら一部で、実際にはさらに倍ぐらいの属性を持つ。

ビットキーにおけるUser Profileの前提

• 弊社は組織をこねくり回すのが大好きな会社なので盛んに変更がかかる, 2週間に1回なにかしら変わってる
• その組織変更時に自動的にOkta User Profileもまるっとアップデートする
• 組織情報(所属情報)をAttributeとして持たせ、そのユーザーがどこ所属で誰さんでどうあるべきか？をProfileだけで判断できるようにしている
• 社内の独自単語でProfile Attributeが構成されているので、ちょっと噛み砕いた言い方で表すと・・・こんな感じ

属性	内容
所属チーム	主務・兼務を問わずまるっとスペース区切りのString[]な感じで入れてある
所属課	同上
所属部	同上
所属事業部	同上
Division	所属部署とかと何が違うんだ？っていう感じだが、ビットキーにおいては、ここはさらに広く区切られた領域。ざっくりいうと、開発か営業かバックオフィスか？の三択。
Organization	所属会社を示す。ビットキーでは業務委託の方々もOktaの中でユーザーデータを持たせているので、その区別のために利用。
isManager	端的に書いちゃってるが、実際にはチームや部署毎にマネージャか否か？を判断できるような属性がある。そうすることで、”管理職である場合にこの権限”みたいなことを簡単にやれるようにしてある

• ざっくりこんな感じの動き
  • これはこれで工夫している部分でもあるのだが、詳細はアドカレの中で誰かが書いてくれると聞いてるのでここでは割愛

Profile Attributeを取ってみる

• Okta Core APIにて言及される Get Current Userをやってみよう

curl -s \
    -H "Accept: application/json" \
    -H "Content-Type: application/json" \
    -H "Authorization: SSWS your_token" \
    "https://your_domain.okta.com/api/v1/users/me" | jq .profile

{
    "lastName": "your",
    "firstName": "name"
    "teams": "hoge foo bar",
	"division": "product",
    "isManager": "true",
}

ビットキーにおけるProfile Arrtributeのユースケース

• 上述の ”組織変更時に自動的にそのProfileが書きかわっている” を前提に弊社におけるユースケースを紹介したい
  • もちろん他にもアイディア次第で色々やれる

Attributeによって所属グループを自動的に切り替え

• 実際にはOktaグループルールとの併用
• グループルールとしてUser Profile Attributeの値をconditionとして利用することが可能
• これにより、 ”この属性を持っているならこのグループに所属しているべき” を定義可能
• そうすることで、このマネージャを集めたOktaグループや、チーム専用Oktaグループみたいなのを簡単に作れる
• Attributeが変われば自動的にグループも変わる
• OktaにおけるSSOアプリケーションのAssignmentとしてOktaグループを利用しておけば、それらもまるっと自動的に変更可能

SAML属性としてマッピングしてSSO先でABAC

• SAMLの属性としてシームレスにUser Profile Attributeをマッピング可能

• つまりSSOした時点で、Oktaが持つマスターとなる所属情報を本来であれば何も知らないSSO先に対してデータを渡せる

• Attributeによってそのユーザーの所属やロールを明白にすることにできるため、そのあとSSO先での認可, アクセスコントロールに使用可能

• これは実際にはSAMLのSP側でそういう機能を持ってないといけないが、今時のSaaSなら大体何かしらのSAML属性による認可機能は備わっているはず

• 弊社の場合だと以下で実用

  • Datadog
    • 社員の所属部署によって ReadOnly, ReadWrite, Admin の3つのロールが切り替わる
    • エンジニアなら原則ReadWrtite
    • 非エンジニアならReadOnly
    • SREチームなど一部のDatadogそのものを管理する必要がある場合にはAdmin
  • Elastic Cloud
    • ElasticSearch + Kibanaのマネージド版
    • そのSSOするエンジニアの管轄プロダクトによってログイン可能な具体のインスタンスが絞られる
      • xxというプロダクト開発に関わるチームメンバーの場合にはxx専用のElasticインスタンスのみにしかSSOできない
  • AWS
    • Elasticと似た感じ
    • エンジニアの社内ロールに応じて、AWS側での利用可能な権限が切り替わる
    • あるいは必要な権限に時間制限をつけたりとか
    • ただし、この仕組みは今はもう最新ではなくて、別のOktaの機能を使ってもっとよりよくしている
    • それについても、別メンバーが明日以降のアドカレ記事で言及予定

• 参考: ElasticのOkta ApplicationのSAML設定画面

  • ここでいうcircleMainというのはビットキーでいうところの”主務の部署”を示すProfile Attributeになる
  • SSOするユーザーがどこ所属の誰さん？を連携し、そのあとの認可処理はElastic側におまかせ

• 例えばAWSの場合はこんな感じ
  • OktaからUserやGroupをProvisioningかつAWS SSOをサポート
  • このときマネージャー？ シニアエンジニア？ ジュニアエンジニア？ をAttributeおよびそこから自動的に形成されたOktaグループによって自動的に権限を分岐
  • 開発系ならエンジニアならとりあえず編集権限を持つが、本番系ならジュニアエンジニアはReadOnlyな権限しか持たない・・・みたいな
    

社内システムとのOIDC連携時にABAC

• 弊社の場合、内製による社内システムがいくつかある
  • 今まではそれらは独自のユーザーデータストアで認証認可を行っていた
• それらを OktaによるOIDC連携に移行
• Oktaによってユーザーの所属情報が管理されており、 OIDC認証によってログイン後に、そのProfile Attribute を使うことで認可処理を簡単に行える
  • この部署所属なので、xxという社内システムにおけるyyとzzという機能は利用可能、みたいな
• 内製による社内システムであるため、その認証と認可は社内のロールやジョブによってアクセスコントロールされるのは筋が通っているし、それをOktaを使えば連携しやすい

どんな嬉しいことがあった？

• 各SaaSでいちいち権限変更とかを行うこともなく、自動的にあるべき権限が付与される
  • 新入社員ジョイン, 社内異動などの際に手間なく迅速に権限が反映
• SaaSのみならず社内システムも同じ仕組みで認証認可を一本化して楽ちん運用
• 同じアプローチをありあらゆるOktaからの連携シーンで利用していけるのでシンプルな構成かつセキュリティ向上に寄与

まとめ

• User Profileは絶対整備してAttributeを仕込んでおいたほうがいい
• OktaはAttribute Basedでめちゃくちゃ連携できるのですっごい夢が広がる
• 手動でAttribute管理するのはかなりしんどいので必要に応じた自動化が必要
  • 弊社の場合はGoogle Apps Script と Okta Workflowsにてそれを自動化
  • アドカレの別記事で言及予定