パスワードを各サーバが持っています。パスワードを共通化することもできますが、この場合でも各サーバ利用時にログインプロセスが必要になります。シングルサインオン環境を構築すると、通常は各々で認証が必要な複数システム(サーバ)に、1つ認証したら他の全てのシステムでは認証プロセス無しにログインできるようになります。サーバへ認証無しでログインできます。電子チケットにはユーザ情報が書かれていますので、そのユーザの権限でそのシステムを利用することができます。使うこと』といった条件があります。実装させることができます。認証については併せて以下も参照下さい。サーバ全般で様々なサービス、プロトコルと連携できます。実装することが少ないです。アプリケーションのためのものになりつつあります。アプリケーションの認証をエージェントに託すようにカスタマイズします。このカスタマイズは必ずできるとは限らないので事前に確認が必要です。提示されなければ"未認証状態"と見做し、認証を要求します。提示すればエージェントが認証済と見做してくれます。サーバ等に聞きに行くパターンもあります。リバースプロキシ型リバースプロキシ型は、全ての連携先サーバへのアクセスが、リバースプロキシサーバ経由になります。パスワードを入力すること無く、ログイン状態になります。サーバ側はカスタマイズは不要ですが、例えば以下のいずれかのような設定にする必要があります。パターンのサーバについては、リバースプロキシサーバからのみアクセスを受け付けるようにする必要があります。クライアントから直接そのサーバにアクセスできると、認証無しでそのユーザ権限の操作ができてしまうため、セキュリティ上の問題となるためです。パスワードが要求されますので、問題にはなりません。(シングルサインオンにはなりませんが。)このリバースプロキシ型の大きなデメリットとしては、構築作業の負荷が高く、構築中に連携できないことが分かるケースがあることです。そのため、動的に生成されるリンクを使うような場合にうまくいかないケースがあります。動的に生成する、といった動作をするものもあります。よるログインはできるけど肝心の動画が見れない、といった状態が発生します。その他のデメリットとして、負荷がリバースプロキシサーバに集中するため、パフォーマンスに注意が必要であることも挙げられます。前述のシングルサインオンでは大きく2つの課題がありました。1つは連携先サーバが自ドメイン(1企業内)に限られることです。サーバに送られないように制限を掛けるのが常識)。近年ではクラウドサービスの発展が目覚ましく、このようなサービスへのシームレスな連携が求められてきました。期待されるようになったのです。1つは規格化されていないことによる適合性の不確かさです。前述の通り、エージェント型ではアプリケーションの認証モジュールのカスタマイズができるかどうかが不明確、リバースプロキシ型では動的なリンク・ディレクトリ構成に対応できるかどうかが不明確、といった問題です。Languageの略。読み方:さむる)という規格が登場しました。SSOサーバに該当します)。対応したものを指します。提示された場合、そのユーザに応じて(属性&属性値によって)適したコンテンツを閲覧させます。例を見ていきましょう。飛ばされ、そこでログインを行います。よるリバースプロキシ経由になることが多いです。(いわゆるドメインコントローラ)のデータベースを使います。ログイン成否を聞きに行くのです。提示することでそのサーバへログインできます。以降はそのAssertionを提示すれば他のサーバへログイン可能となります。規格としては暗号化して防ぐ仕組みを決めていません。暗号化することが推奨されています。加えてデジタル証明書による暗号化/復号化も行っています(トークン暗号化解除証明書)。アプリケーションでは、連携が可能であることが事前に明確に分かるようになりました。1企業専用ではなく、複数の企業が共有することができます。より各企業で用意し、他のリソース(CPU/メモリ/HDD(メール領域)/サービス)についてはクラウド側のものを他の企業と共用で使うことができるのです。仕組みを利用して、コンテンツまで共有させるものもあります。このような構成をフェデレーションと言います。大学等のアカデミック機関のフェデレーションとして『学認(GakuNin)』があります。大学間で情報を共有するためのものです。認証が使われています。SAMLではどのように所属組織を識別するか(あるユーザの認証を、どのIdPに聞きに行けばよいか)、その方法については規格では指定しておらず、実装に委ねられています。埋め込むか、ログインユーザの後ろに@と識別子を付け加えるか、あるいはその両方です。場合はログイン画面にずばりその所属組織をプルダウン等で選択させます。ようなログイン画面になります。提示することでログインが為されます。ログイン」といった表示をするアプリケーションが増えていますが、これはこれらの技術を使っています。扱うSAMLとは異なり)認証情報だけを提供します。ID認証機能を提供するのです。間の事前の信頼関係構築が無いこと、アサーションのようなセキュリティトークンを利用しないことが挙げられます。低負荷で手軽に実装できるといったメリットがある反面、セキュリティ強度が低くなるというデメリットがあります。認証技術ではなく、認可技術です。異なり、ID認証機能だけでなくコンテンツそのものを提供します。アカウントへ自由にアクセスできるようになります。情報を使っていいよ』と認可するのです。渡す行為に等しいです。宣伝を投稿する、といったこともできてしまいます。技術の進化はとどまることを知りません。AM分かり易い図解ありがとうございます!エージェント型の解説ですが、WebアプリB側のエージェントの動作も図解してもらえるとうれしかったかもです。アプリAの初回アクセス時にアプリBにも認証Cookieが発行されるわけじゃないですよね?(それはできないと思うで)とすれば、アプリBがどうやって認証済みを確認するのか?の説明がないと、SSOの説明としては不足するような気がするのです。PMひろさんコメントありがとうございます。ご指摘ありがとうございます。たしかに表現が分かりにくかったので図を修正してみました。同じアプリでも別のWebアプリでも同じ動作になります。アプリAで払い出された認証CookieはアプリBにも流用され、その背後のSSOサーバで「どのCookieがどのユーザのものか」を識別し、認証します。気になる点や不明点などありましたら、ご指摘頂けるとありがたいです。今後も当サイトを宜しくお願い致します。いうところですが、たいがいのSSO解説で同じように説明されているのですが、それが可能になるのは、アプリAとBが同じdomain指定のcookieを共有できるときのみですよね?アプリAとBが同じdomainにあるのなら、そもそもSSOサーバーやエージェントが登場しなくてもSSOが可能になると思うのです。domainが異なれば、アプリAが認証済みでもアプリBにcookieが届くことはないので、そこにエージェントが登場してくると思うので、その部分の説明があると他とは違う説明になるような気がしました。AMひろさんまたまたコメントありがとうございます。私の勉強不足かもしれませんが、私の理解とは異なりますね。それが可能になるのは、アプリAとBが同じdomain指定のcookieを共有できるときのみですよね?はい、この部分は認識合います。この課題を解決するために、SAMLが登場したという認識です。SAMLではCookieに頼らず、ドメイン間で信頼関係を結んだ後に、ドメイン間で認証情報を(httpsで)やり取りすることでセキュリティを保ちます。アプリAとBが同じdomainにあるのなら、そもそもSSOサーバーやエージェントが登場しなくてもSSOが可能になると思うのです。この部分は私の理解と異なります。ActiveDirectoryのドメインのことを仰っているのであれば統合Windows認証等によりSSOが可能になりますが、Cookieで言うドメインは別の概念なので、SSOサーバ無しでSSOが可能になることは無いと思っているのですが、いかがでしょうか。AMあ~なるほど、エージェント方式ではdomainを跨げないということですね!(ちゃんと明確に説明されていましたね;)すみません、そこを誤解していました。自分が作成していたasp.netなwebアプリでは、特にエージェントとかSSOサーバーを意識せずにSSOが実現できていたので、エージェントの定義を誤解していたみたいです。お手数おかけしました。PMasp.netのSSOは知らなかったです。asp.netのライブラリがSSOサーバ兼エージェントとなり、認証DB自体はActiveDirectory等で共有化する感じなんですかね。いずれにせよ、勉強になりました。ありがとうございます。コメントをキャンセルメールアドレスが公開されることはありません。WordPress.。