こんにちは。スプラッシュトップ編集部です。
企業においてシステムやサービスの導入が拡大するにつれて、課題となるのがユーザーのID管理です。クラウドサービスの導入が進み、業務で社内システムとクラウドサービスを併用する機会も増えています。
こうした複数のサービスやシステムにおけるID管理の際に重要な役割を果たすのがSCIMやSAMLです。クラウドサービスの利用が一般的になった今、これらのID管理技術は欠かせない要素となっています。
今回は、SCIMの概要や仕組み、およびSAMLとの役割の違いについて解説します。
SCIMはIDプロビジョニングプロトコル
SCIMは自動的なIDプロビジョニング（提供・同期）を実現するためのオープンな標準規格です。以下でより詳しくみていきましょう。
SCIMの概要
SCIMはSystem for Cross-domain Identity Managementの略称であり、複数のドメイン間でユーザーID情報のやり取りを自動化するために作られた規格です。
つまり、複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するプロトコル（規格）がSCIMとなります。
2011年に最初のバージョンであるSCIM 1.0が登場し、2015年にバージョンアップが行なわれて以降は、SCIM2.0が利用されています。
SCIMが広く採用されるようになった背景
SCIMが登場した2011年頃から、将来的にクラウドベースのテクノロジーが主流になることが予見されており、異なるドメイン間でのユーザー認証情報のやり取りが可能なプロトコルが求められていました。
当時からSCIMのようなユーザーID管理のためのプロトコルや仕様は多く登場していました。SCIMのほかには、SPML（Service Provisioning Markup Language）やITML（Information Technology Markup Language）、WS-Provisioningなどが代表的な例です。
しかし、これらのプロトコルは複雑な仕様やアプリケーションベンダーのサポートが少ないなどの問題を抱えていました。
こうしたなかSCIMでは、ユーザー管理の標準化や複雑な仕様を排除するなどの対策が進められ、結果多くのID管理製品に採用されて標準的な規格となっていきました。
そして、近年テレワークの増加などにより企業のクラウドサービス利用が本格化したことで、社内外のシステムのユーザーID管理を実現する手段としてSCIMが注目を集めています。
SCIMの仕組み
次に、SCIMが自動的なIDプロビジョニングを実現する仕組みについて解説します。
JSON＋HTTPで認証情報をやり取り
SCIMはユーザー認証情報をJSON形式でHTTPを使ってやり取りします。
JSONとはデータ変換フォーマットのことであり、JavaScript Object Notationの略称です。JavaScriptの書き方をもとにしたデータ定義方法を表し、さまざまなサービスやシステムにおけるデータのやり取りで利用されています。
具体的には次のようなものがJSON形式のデータとなります。
{
"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プロビジョニングの自動化を実現しています。
※
IdP：ユーザーの代わりにSPと認証情報をやり取りするサービス・事業者
SP：クラウドサービスなどのサービス・事業者
ユーザー認証情報の変更も自動的に同期
SCIMを利用すれば、IdP側で行ったユーザーIDの作成・更新・削除が、SCIMプロトコルにしたがって自動的にSP側に同期されます。
IdPとSPで、常に最新のユーザー認証情報が管理、更新されるので、退職などで不要となったユーザーIDがSP側にいつまでも残るような事態が避けられます。これにより、退職者などを通じた不正アクセスのリスクが回避できます。
これは、クラウドサービスの利用が一般的になった現在では非常に重要な機能です。
これまで、社内システムはActive Directoryなどでユーザー認証情報を連携していましたが、社内システムとクラウドサービスを併用する機会が多くなり、クラウドとも連携させる必要性がでてきました。
社内システムとクラウドサービスは異なるドメインのため、通常は連携させることが困難ですが、異なるドメイン間での認証情報の同期を可能にするSCIMを活用することで、その問題を解決することができます。
SCIMとSAMLの役割の違い
ここでは、SCIMと一緒にでてくることが多いSAMLとの違いについて、それぞれの役割や形式に焦点を当てて説明します。
役割の違い：IDプロビジョニングとフェデレーション
SCIMとSAMLはそもそもプロトコルとしての考え方が異なります。SCIMはIDプロビジョニングプロトコルであり、SAMLはフェデレーションプロトコルです。
フェデレーションとは、一度認証を通せば許可されているすべてのサービス・システムを使えるようにする仕組みのことです。
SAMLが認証を中心としたプロトコルとなっているのに対し、SCIMはユーザー認証情報の提供や同期を中心としたプロトコルであり、認証や認可の仕組みは持ちません。
そのため、SAMLは複数のシステム間での一括ユーザー認証（シングルサインオン）等を実現するために利用されますが、SCIMは異なるシステム間でのユーザーを構成する要素（属性）の連携のために利用されることが多い、という違いがあります。
SCIMにおける認証・認可はOAuth 2.0の利用が推奨されており、実サービスでも認証・認可はOAuth 2.0で実装されている場合が多くなっています。
形式の違い：JSONとXML
SCIMとSAMLはデータをやり取りする際のフォーマットも異なります。SCIMはJSON形式でやり取りしますが、SAMLはXML形式でやり取りします。
XML形式はHTMLの記法をもとにしたデータ定義方法であり、HTMLと同様にタグを使ってデータの構造を定義するものです。
XML形式はJSON形式が登場する前まではデータのやり取り手段として一般的でしたが、現在ではJSON形式でやり取りすることが多くなっています。
まとめ
SCIMは複数のドメイン間でユーザー認証情報をやり取りするためのプロトコルです。
企業の業務においては、社内システムだけでなくクラウドサービスの利用も進んでいます。こうしたなか、SCIMはさまざまなドメイン間でのユーザー認証情報を一元的に管理して整合性を取るために利用されます。
SAMLとの大きな違いは、SAMLが認証に利用されるプロトコルであるのに対して、SCIMは属性情報の連携に利用されるプロトコルだという点です。
近年注目を集めているシングルサインオンを実現する方法としてSAML認証が取りざたされていますが、セキュリティリスク低減などを目的に併せてSCIMが採用されることも多くなっています。
シングルサインの導入を検討する際には、SCIMの採用も視野に入れてみてはいかがでしょうか。
＞SCIMが利用できるIdPとの連携が可能なリモートデスクトップはこちら
