自転車なしの同時クロスサイト認証

同時クロスサイト認証（SSO）、なぜ必要なのですか？ ブログ、写真、失敗（またはファイルなど）を含む時代錯誤用語「ポータル」と呼び、fail.ru（Mと同じ名前のメールサービスと混同しないでください）と呼びます。これはすべて、次の要因によって複雑になります。 ：

-機能がまったく異なります。

-コードは、さまざまな人々がさまざまなテクノロジーを使用して作成しています。

-これらはすべて、異なるデータセンターの異なるサーバーおよび異なるデータベースで動作します。

-サーバーは異なるドメインにあります。



そして、このようなKoshcheiでは、卵を割ってユーザーに1回だけログインする機会を与え、その後、身元を確認せずにすべてのフレンドリーなリソースにアクセスする必要があります。



これについてはすでに多くのことが書かれており、コードについても同様です。 しかし、私たちは自転車の建物の荒廃した道を進むことはありませんが、本物のエンジニアとして既製の開発を行い、それらを使用します。 この方法は単純で、そのような困難な状況にも適しています。



次に、自己記述の代替案、OpenID、OAuth、SAML、およびこれらすべてが一般的に良い解決策ではない理由、認証データの保存の問題、および適切な知識なしで行ってはならないセキュリティの問題、クロスサイト認証とは何か、いくつかの神話を払拭します。

普遍的でない場合の成功したソリューション

実際には、考えている場合ほど物事は開始されておらず、一般的なCookieを設定することでソリューションを回避できる場合もありますが、外部ドメインが表示されるか、セッションを保存するための一般的なデータベースが消えるとすぐに、ソリューションは消えます。



ここで説明されているオプションを使用できますが、コメントには、iframe、javascript、その他についてかなり多くの否定性があります。

Openid

ネットワークには、OpenID自体が発明した問題を解決するという非常に興味深いメモがあります。 OpenIDは、メールと認証するサイトの間の不要なレイヤーです。 たとえば、coolopenid.netにはメールに関連付けられているアカウントがあります。 ターゲットサイトを入力すると、coolopenid.netに送信され、そこで既にログインしている場合はCookieが表示されるか、電子メールとパスワードを要求してIDを確認し、ターゲットサイト（foo1@coolopenid.netなど）を入力します。 確かに、メールリンクで確認するよりも簡単ではありませんか？



クロスサイト認証の場合、ユーザーが各サイトの入り口で自分の身元を確認する必要があるため、OpenIDは多くの友好的なサイトではあまり便利ではありません。

OAuth

OAuthは、サードパーティのサイトでの認証とプロバイダーのWebサイトでの承認という二重のタスクを実行します。ユーザーにサードパーティのリソースの機能を使用してプロバイダーのWebサイトの機能を拡張する機会を与えます。たとえば、Twitterの写真へのリンクのアップロード、Facebookの現在の場所に関する情報の追加 違いの良い説明はこちらです。 これはすばらしい便利なものですが、異なるサプライヤのサイトを結合するように設計されていますが、ユーザー名の共通の中央リポジトリがまだあります。

SAML

少しの批判は害にはなりませんが、社内および社外のプロジェクトが多数ある巨大企業のインフラストラクチャにこのソリューションを実装した同僚の経験があまり成功していないことを間接的に証言することしかできません。 さらに、さまざまなプログラミング言語用にこのプロトコルを実装するライブラリの数はそれほど多くありません。

キャス

読者は、正しい選択の独自性を彼に納得させようとすることで、私が一つのことになりがちであることをすでに認識しているに違いない。 はい、いいえ。 私は自分の投げ、選択、練習を説明したかった。 明確な選択はありませんが、CASは私のニーズと知識ベースに最もシンプルで包括的なソリューションです。



CASは、同時クロスサイト認証用に特別に設計されたプロトコルです。 このプロトコルには少なくとも2つの 実装があり 、 そのうちの少なくとも1つが積極的に開発されています。 2番目の方が有利な選択は、サーバーが多くのJava依存関係を恐ろしい方向にドラッグする必要がないという事実によってサポートできます（多くのRuby依存関係を恐ろしい方向にドラッグする必要性を損ないます）。



また、利点として、CASはシッククライアントでも機能し、クライアントエージェントからCookieを設定する機能さえ必要としないことにも注意できます。 CASを介したユーザー認証の簡単な統合のために、さまざまなプラットフォームに十分なクライアントがあります。



CASはあまり機能しません。 ユーザーに関するデータは保存せず、ユーザーの役割も保存せず、他のメンバーについては何も知りません。 ユーザーリポジトリとして、次を使用できます。

-データベース

-LDAP / AD

-SPNEGO

-RADIUS

-サードパーティのサービス

-...はい、テキストファイルでも



2要素認証、およびX.509証明書を使用するusbトークンで使用することが可能です。

クリトカと神話

CASは開発されていない古いプロジェクトです。 サーバーの現在のバージョンは3.4.8で、プロトコルの最新リビジョンは2005です。

最新の更新は今年11月9日です 。

どうやら、プロトコルはSSOのニーズに必要な機能を完全に実装しており、たとえば1999年6月以降HTTPプロトコルが更新されていないため、さらなる開発は必要ありません。

CASは人気のないプロジェクトです。 彼は1歳ではないという事実にもかかわらず、彼は認められませんでした-ほとんど誰も。 120の学校、単科大学、総合大学が1つ以上を使用しているという事実は、他の誰も使用できないことを示唆しています。

この実装を使用するすべての人がここに示されているという事実ではありません。

CASは、特定のタスクのために1つの会社によって開発されています。 CASを書いたプログラマは、教育ポータルの作成に取り組んでいます 。

私は、これらの人々は誰か他の人の共通の仕事のためのソフトウェアを作るような後援者ではないと仮定します。 そして、それが行われたので、一般的なアクセスで与えることは残念ではありません。

CASは、非常に狭い応用分野（大学、学生管理）を除き、他の誰かのソリューション（uPortal）を除いてどこにも本当の成功事例を持たない民間開発です。

議論中のトピックで言及されている他のソリューションについても同じことが言えます。 おそらく、私は何かを知りません。

驚くほど小さなコミュニティ。 一般的なプロパティの典型的なエラーをネットで検索すると、100件のレビューしか見つかりません 。

右見て。 約3,210,000件の結果（0.21秒）。 引用符で囲む場合、つまり、完全一致の7.5千を探します。

驚くほど少数の実装。 実際には、CASサーバーの実装は2つだけです。 また、OpenIDプロバイダーの何百もの実装が記述されていますか？

上記のように、OpenIDは代替ではありません。 実装の数は、統合の容易さを意味するものではありません。

動作原理

最初のエントリ。

1.ユーザーが、登録ユーザーのみがアクセスできるページにアクセスします。

2.サイトはCASサーバーへのHTTPリダイレクトを行います。

3.ユーザーはユーザー名とパスワードを入力します。

4.必要なアダプターを介したCASが正しいユーザー名とパスワードを決定します。

5.認証が成功した場合、CASサーバーはユーザーをサイトに成功したログインページとして示されるページにリダイレクトし、リクエストにサービス検証チケットを添付します。

6.サイトは、チケットの検証のためにCASサーバーに対して内部クロスサイトHTTP要求を作成します。

7.ユーザーは承認されています。ユーザーは、セッションCookieをCASサーバーから受信したログインに関連付けることができます。



再ログイン（たとえば、サイト2に）。

1.ユーザーが、登録ユーザーのみがアクセスできるページにアクセスします。

2.サイトはCASサーバーへのHTTPリダイレクトを行います。

3. CASサーバーはユーザーのCookieを確認し、サイトで成功したログインページとして示されているページにユーザーをリダイレクトし、リクエストにサービス検証チケットを添付します。

4.サイトは、チケット検証のためにCASサーバーに対して内部クロスサイトHTTP要求を作成します。

5.ユーザーは承認されています。セッションCookieをCASサーバーから受信したログインに関連付けることができます。



このメソッドは、十分な数のセキュリティホールを閉じます。

設置

1. Rubyバージョンマネージャー

bash <<（curl -s raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer ）

echo '[[-s "$ HOME / .rvm / scripts / rvm"]] &&。 "$ HOME / .rvm / scripts / rvm"＃RVM関数のロード '>>〜/ .bash_profile



2.ルビー

rvm install 1.9.2

rvm use --default 1.9.2

gem install bundler



3. ruby​​cas-server

git clone git@github.com： rubycas /rubycas-server.git

cd ruby​​cas-server

バンドルインストール



4. Thin（Webサーバー）をインストールして起動します

gem install thin

シンスタート

これは最も簡単ですが、最良のオプションではありません。 ユニコーンとnginxで実行することを検討する価値があります。

クライアント使用

Ruby / Rack / Sinatraアプリケーションの例：



Gemfile：

...

gem 'oa-enterprise' ,: require => 'omniauth / enterprise'

...



アプリケーション：

...

設定：login_page、 "/ auth / cas"



OmniAuthを使用::戦略:: CAS 、: cas_server => 'https://ruby-cas.mydomain.com'



「/ auth / cas / callback」を取得します

auth = request.env ["omniauth.auth"]

account = Account.first（：email => auth ["uid"]）|| Account.first（：電子メール=> auth ["uid"] ,:役割=>：外部）

set_current_account（アカウント）

リダイレクト '/'

終わり

...