第二回で、「保存」について説明しました。「Identityに関する情報」が、一箇所に「保存」されていていることの重要性についてです。複数の場所に保存されているのではなく、一元管理されることで、常に新しく、正しい「Identity情報」の保存と、参照が可能であることを説明しました。 一箇所に保存されていない場合には、同期の必要があったり、同期するまでは、一方が古い情報を持つことになります。一箇所に情報があれば、常にそこが正であることを保証することができます。

第三回で、アクセスしてきた人が誰なのかを確認する、「認証」について扱いました。システム側では、アクセスしてきた人が誰なのかを同定し、その人が正しく登録済みの人であるのか確認する必要があります。それが認証です。第二回で説明した「保存」の機能で保持されている「Identity情報」と「アクセスした人」が合致しているか、様々な方法で確認します。

第四回では、認証によって判明したユーザに対して、どのようなサービスを使わせるかを管理する「認可」を扱いました。実際の運用を考えると、

• 営業担当者には、Salesforceを使わせる
• サポート担当者には、Zendeskを使わせる
• 全社員に、G SuiteとSlackを使わせる。

というように、グループに対して、サービスを「認可」することができます。これは、どのユーザがどのグループに属しているかという情報が、IDaaSに「保存」されているためです。

第五回では、「プロビジョニング」について扱いました。プロビジョニングが出来ない場合は、対象サービス側の管理画面から、アカウントを作る必要がありますが、プロビジョニングに対応している場合は、連携するサービスに対して、「アカウントの作成・更新・削除」をすることが出来ます。 つまり、IDaaSにアカウントを作成し、対象サービスを認可することで、対象サービス側には、アカウントが作成されますし、認可を取り消せば、削除(あるいは無効化)されることになります。または、認可をグループで管理していれば、特定のグループに所属させることで、対象サービスにアカウントが作成され、グループから外せば、削除(あるいは無効化)されます。ここが自動化されていない場合は、運用において大きな違いがあります。

第六回では、「シングルサインオン」について扱いました。シングルサインオン(SSO)は、利用者の側からの視点と、管理者からの視点でその意味が大きく異なります。利用者の視点に立つと、

• 一度ログインすれば、使って良いサービスはすべて使える
• ID/パスワードをそれぞれ別々に覚えなくても良い

という利点があります。また、管理者にとっては、ユーザが杜撰なパスワード管理をする可能性が低くなる点と、サービス利用の停止が容易である等の利点があります。

前回までの内容を簡単にまとめてみました。これらの機能は、それぞれ他の機能を利用する立場にあります。ここまでの説明で断片的に出ていますが、全体としてどのように動くのか、簡単な運用例にあてはめてみましょう。登場するのは、「管理者」「利用者」「IDaaS」「サービス」です。

1. 管理者は、IDaaSに利用者のアカウントを作成する。
2. 管理者は、IDaaSで、利用者に連携するサービスを認可する。
3. 利用者は、IDaaSのログイン画面から、ログインする。
4. 利用者は、サービスを利用する。

この流れを少し詳細に見てみます。

1.で利用者の「Identity情報」がIDaaSに保存されます。この段階では、まだIDaaSにあるだけです。

2.の認可により、プロビジョニング機能を使って、連携するサービスにアカウントが作成されます。

3.では、認証機能により、ログインして、シングルサインオンにより、対象機能にログインしていることになります。これらの機能が協調することで、

4.で利用者はサービスを利用することができます。


では、もう少し複雑な例として、利用者が他の部署に異動する例を考えましょう。
具体的な方が分かりやすいので、以下のような例を想定します。

• 「山田太郎」が「開発部」から「営業部」に異動する。
• 開発部では、Slackを利用する。
• 営業部では、Salesforceを利用する。
• 全社員が、G Suiteを利用する。

異動のタイミングでの管理者の処理から始まります。
ただし、前提条件として、

• 開発部グループには、Slackが認可されている。
• 営業部グループには、Salesforceが認可されている。
• 全社員グループには、G Suiteが認可されている。

という設定がされているものとします。

1. 管理者は、IDaaS上で、開発部グループのメンバーから、山田太郎を削除する。
2. 管理者は、IDaaS上で、営業部グループのメンバーとして、山田太郎を追加する。
3. 山田太郎は、IDaaSのログイン画面から、ログインする。
4. 山田太郎は、G Suite、Salesforceが利用でき、Slackが利用できない。

この流れも詳細に見てみます。

1.でSlackの山田太郎アカウントは、プロビジョニング機能により、削除か無効化されます。削除か無効化としているのは、対象サービスや、IDaaSの仕様によるからです。どちらにしても、山田太郎は、Slackを使えなくなります。

2.で、Salesforceに山田太郎アカウントが作成されます。これ以降は、前述の例と同様で、

3.で認証機能により、ログインし、

4.では、シングルサインオン機能によりG SuiteとSalesforceにはログインしている状態となっているので、そのまま利用可能です。

一方で、以前は使えていたSlackは使えないということになります。

「IDaaSとは何か」というテーマで、7回にわたってその機能について掘り下げみました。

IDaaSという耳なれない言葉について、身近なものとして理解するための一助となればと思います。多くのクラウドサービスが、提供されていますが、それを有効に使うためには、クラウドサービスを管理、運用するためのサービスも必要になります。

それがなければ、結局運用は破綻し、せっかく有用なサービスも使われないか、なりすましや、不正利用されることもあり得ます。 IDaaSは、ユーザにも、管理者にも非常に有用なサービスです。導入をご検討ください。弊社では、豊富な実績のあるIDaaSサービス「Gluegent Gate」を提供しています。IDaaSの必要性に納得いただけましたら、ぜひ、ご相談ください。