Closed5

[キャッチアップ] SCIM

shingo.sasakishingo.sasaki

SCIM を仕事で使うので、ググって軽く要点だけ抑えておく

shingo.sasakishingo.sasaki

https://qiita.com/naka_kyon/items/58e3c55282e997aaef47

SCIM はプロビジョニングやデプロビジョニング用のID情報を Restful なAPI で CRUD で操作するときの標準プロトコル

なるほど。これだけで物凄い大雑把なイメージが湧いた。

システム間でユーザープロビジョニングする際に、こういうリクエストをすれば良いよっていう標準ルールがあれば連携しやすくなるよっていう話ね。

ある Webサービスが SCIM に準拠した API を提供しているって関係性か。

SCIM は System for Cross-Domains Identify Management の略らしい。
あまり名前から実態のイメージはできない。

SCIMの仕様には認証・認可に関する仕様は定義されていません。 推奨はOAuth2.0 ベアラートークン。

あくまで Restful インタフェースの定義に集中してるという話かな。

shingo.sasakishingo.sasaki

https://www.splashtop.co.jp/knowhow/29/

SCIMは自動的なIDプロビジョニング(提供・同期)を実現するためのオープンな標準規格です。

提供・同期を実現するって言われるとさらにイメージが深まる

つまり、複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するプロトコル(規格)がSCIMとなります。

うんうん。最初に Qiita で Restful のプロトコルってことを確認しておいたおかげでわかる。最初にコレ見せられたらわからなかった。

こうしたなかSCIMでは、ユーザー管理の標準化や複雑な仕様を排除するなどの対策が進められ、結果多くのID管理製品に採用されて標準的な規格となっていきました。

同じ目的を持ったプロトコルは他にも色々あったけど、そのシンプルさから一番普及したのが SCIM なのか。

            {
                "schemas": [
                    "urn:ietf:params:scim:schemas:core:2.0"
                ],
                "id": "0001",
                "userName": "tarotanaka@example.com",
                "externalId": "ttanaka",
                "name": {
                    "familyName": "tanaka",
                    "givenName": "taro"
                }
            }

SCIMでは、このJSON形式のユーザー認証データをIdP(Identity Provider)やSP(Service Provider)※とやり取りし、IDプロビジョニングの自動化を実現しています。

たぶんリクエストボディのスキーマとかも厳格に決められてるんだろうな

SCIMを利用すれば、IdP側で行ったユーザーIDの作成・更新・削除が、SCIMプロトコルにしたがって自動的にSP側に同期されます。

IdPとSPで、常に最新のユーザー認証情報が管理、更新されるので、退職などで不要となったユーザーIDがSP側にいつまでも残るような事態が避けられます。これにより、退職者などを通じた不正アクセスのリスクが回避できます。

はいはいはい。SP 側が SCIM に準じたAPIを提供する限り、 SCIM に基づいて IdP が SP にリクエストを投げてくれるから、まぁ同期してくれるわけね。 (SP側がバグってたらダメそうだけど)

そのため、SAMLは複数のシステム間での一括ユーザー認証(シングルサインオン)等を実現するために利用されますが、SCIMは異なるシステム間でのユーザーを構成する要素(属性)の連携のために利用されることが多い、という違いがあります。

SAML と SCIM は確かに同じ文脈で出てきそうだけど、目的もアプローチも何もかも違うよね。 SSO 実装のために SAML だけ使うってことも普通にあるわけだし。

shingo.sasakishingo.sasaki

https://support.trustlogin.com/hc/ja/articles/231917928-SCIM-System-for-Cross-domain-Identity-Management-スキム

企業や組織で利用する情報システムのユーザー管理においては、理想的には「1つのドメインに全てのユーザーID情報が紐づき、ドメイン情報を変更するとその変更が自動的に全システムに反映される」ことが望ましい。

自分は情シスではないけど、アカウント管理の文脈で考えたらそれはそうか。社員が一人増えた時にN箇所でアカウント発行して共有するとかアレだしね。

かつての社内システムは、Active Directoryなどのドメインを中心として、それにほぼ全てのシステムを連携させるよう設計されていた。しかしながら、クラウドサービス(特にSaaS)の業務利用が一般的になり、システムを自社開発または自社の物理サーバーに導入することが激減したため、社内の業務システムとSaaSを容易に連携できる規格であるSCIMに注目が集まることとなった。

そうか。社内システムが社内に閉じてるんだったら AD で充分だもんね。

SCIMを利用することで、あるユーザーID情報が変更された場合に、その変更を容易に反映させられるようになった。具体的には、最も基本的な「レコードの作成・削除」に加えて、ユーザー属性情報、属性スキーマ、グループへのアクセス権といった情報の管理も行うことが可能である。

ユーザーが所有している属性ってのがサービスによってマチマチで扱いが難しいとかはあるかもしれない。アクセス権とかそんな都合よくまとめて管理できるのかなぁ。
(たぶんそのへんの設定に関しては IdP 側で SP別に制御できるんだと思う)

このスクラップは2021/10/09にクローズされました