こんにちは。サイオステクノロジーの有村です。
前回はShibbolethを理解する準備としてHTTP,HTTPS,SSLを勉強しました。
新卒がShibbolethを学ぶ ～その1:HTTP,HTTPS,SSLって何？～
今回もShibbolethを理解するためにシングルサインオンについて勉強したのでアウトプットしていきたいと思います。
シングルサインオンとは
シングルサインオンとは一回の本人認証で複数の異なるアプリやシステムを利用できるようにする仕組みのことです。
シングルサインオンを導入することによって以下のメリットがあります。
- エンドユーザーのメリット
- システム毎にログインする手間が省ける
- パスワード忘れに伴う負荷を減少出来る
- 管理者のメリット
- パスワードを覚えきれないユーザーに対応する負荷を減少出来る
- パスワード流出のリスクを低減できる
シングルサインオンを導入することで下のイラストのような煩わしさから解放されます。
今回は４つのシングルサインオンを取り扱います。
※４つのシングルサインオンの説明中に出てくるエージェントとはユーザーが指定した情報を自動的・効率的に送受信を可能とするソフトのことです。
代行（代理）認証方式
代行（代理）認証方式とはクライアントPCに導入したエージェントがシングルサインオンの対象となるシステムのログイン画面を監視して、ログイン画面が起動したらユーザーの代わりに認証情報を入力してログインする仕組みになります。
代行（代理）認証方式によるシングルサインオンの流れ
代行（代理）認証方式によるシングルサインオンの流れは以下のようになります。
- クライアントからアカウント情報DBにユーザー認証を行う
- アカウント情報DBから各システムのIDとパスワードをクライアントに送る
- 取得したIDとパスワードをクライアントのメモリ上に保存する
- 各システムのログイン画面をエージェントが検知してIDとパスワードを自動入力する
代行（代理）認証方式のメリット・デメリット
代行（代理）認証方式をには以下のメリットとデメリットがあります。
- メリット
- レガシーシステム（古いシステム）にもSSOを導入することが出来る
- SSOを導入する際にアプリ側は改修する必要がない
- 認証情報をデータベース内で管理するので権限レベルで管理が可能になる
- デメリット
- クライアントPCにエージェントを導入しないといけない
（クライアントPCが増えると、導入がきつい） - サービスの追加対応が困難
- クライアントPCにエージェントを導入しないといけない
リバースプロキシ方式
リバースプロキシ方式とはクライアントとWebシステムの間にリバースプロキシサーバを設置してシングルサインオンを実装する方式です。
プロキシサーバ・リバースプロキシサーバとは
プロキシサーバとリバースプロキシサーバの違いはどこにサーバを設置するかの違いになります。
プロキシサーバの場合はインターネットとクライアントPCの間に設置するので「クライアントのリクエスト要求を代理するサーバ」になります。
リバースプロキシ方式に使われるリバースプロキシサーバはインターネットとWebサーバの間に設置されるので「Webサイトへのリクエスト受理を代理するサーバ」になります。
リバースプロキシ方式によるシングルサインオンの流れ
リバースプロキシ方式によるシングルサインオンの流れは以下のようになります。
- クライアントからリバースプロキシサーバにアクセスしてWeb認証を実施する
- リバースプロキシサーバからクライアントに認証Cookieを発行する
- クライアントから各Webシステムにリバースプロキシサーバー経由でアクセスする
リバースプロキシ方式のメリット・デメリット
リバースプロキシ方法には以下のメリットとデメリットがあります。
- メリット
- リバースプロキシサーバにのみエージェントを導入すればよい
- プラットフォームに依存することなくSSOの実現が可能
- Webシステムサーバの存在を隠すことが可能になる
（リバースプロキシサーバにアクセスすることになるから）
- デメリット
- リバースプロキシサーバ経由になるようにネットワーク構成を変更する必要がある
- アクセスがすべてリバースプロキシサーバ経由になるのでリバースプロキシサーバがボトルネック（障害）になるケースがある
- Webシステムを使う場合はID、パスワードがネットワークに流れるのでセキュリティを考慮する必要がある。
エージェント方式
エージェント方式とは各Webシステムにエージェントを導入してシングルサインオンを実装する方式です。
エージェント方式によるシングルサインオンの流れ
エージェント方式によるシングルサインオンの流れは以下のようになります。
- クライアントからWeｂシステムにアクセスしてWeb認証を実施する
- Webシステムからシングルサインオンサーバにアクセスして認証情報の確認を行う
- 認証情報の確認が終わり次第Webシステムからクライアントに認証済みCookieを発行する
- Cookieを保持しているのでアクセス権限のあるWebシステムにアクセス出来るようになる
エージェント方式のメリット・デメリット
エージェント方法には以下のメリットとデメリットがあります。
- メリット
- シングルサインオン導入のためにネットワーク構成を変更する必要がない
- 拡張性が高い
- ユーザーの利用記録の特定が容易
- デメリット
- Webサーバにエージェントを導入する必要がある
- サーバのプラットフォームによってエージェントが対応していないケースがある
- Webシステムを使う場合はID、パスワードがネットワークに流れるのでセキュリティを考慮する必要がある。
SAML認証
SAML認証とはSAML（Security Assertion Markup Language)というXMLをベースにした標準規格を使って異なるインターネットドメイン間でユーザー認証を実装する仕組みになります。SAML認証はリバースプロキシ方式やエージェント方式と違い、Cookieを利用しないシングルサインオンの仕組みです。
SAML認証を理解するときにSPとIdPという単語を知っている必要があるので説明していきます。
SP（Service Provider）とは
SPはシングルサインオンを利用してログインするサービスのことです。SAMLによるシングルサインオンを行うにはログインするサービスがSAMLに対応している必要があります。
IdP（Identity Provider）とは
IdPはシングルサインオンの認証を行うサーバの（サービス）のことです。SAMLによるSSOを行うには認証サーバがユーザー情報を保持している必要があります。
SAML認証によるシングルサインオンの流れ
SAML認証には２つのシングルサインオンの方式があります。
SPからシングルサインオンを開始する方式をSP-initiated SAML、
IdPからシングルサインオンを開始する方式をIdP-initiated SAMLと言います。
SP-initiated SAMLによるシングルサインオンの流れは以下のようになります。
- クライアントがクラウドサービス（SP）にアクセスする
- クラウドサービス（SP)はSAMLリクエストを生成する
- SAMLリクエストと共に認証サーバ（IdP）にリダイレクトする
- 認証サーバからクライアントにログイン画面を表示する
- クライアント側でログインする
- 認証サーバでSAMLレスポンスをクライアントに返す
- SAMLレスポンス共にクラウドサービス（SP）へリダイレクトする
- クラウドサービス（SP）にログイン成功
IdP-initiated SAMLによるシングルサインオンの流れは以下のようになります。
- クライアントが認証サーバ（IdP)にアクセスする
- 認証サーバからクライアントにログイン画面を表示する
- ログインすることでアクセス情報（SAML Token)を提供
- クライアントにポータルサイトが表示される
- ポータルサイトのアプリケーションをクリック
- 認証サーバからクライアントにSAMLレスポンスを返す
- SAMLレスポンス共にクラウドサービス（SP）へリダイレクトする
- クラウドサービス（SP）にログイン成功
SAML認証のメリット・デメリット
SAML認証には以下のメリットとデメリットがあります。
- メリット
- 異なるインターネットドメイン間でユーザー認証を実装することが出来る
- シングルサインオンサーバ及びクラウドサービスの設定のみで導入が出来る
- デメリット
- SP,IdP両方ともSAMLに対応している必要がある
まとめ
今回はシングルサインオンについて勉強しました。私自身まだ、完璧に理解したと断言できる状態ではないのですが、この記事を書くことで頭の整理が出来た気がします。皆さんもこの記事を読んで少しでも役に立ったと思ってくだされば嬉しいです。
次回はShibbolethを実装するためのLDAPサーバの実装をしていきたいと思います。
