プロキシサーバーがあります。キャプティブポータルページがあります。ユーザーは、インターネットにアクセスする前にサインインする必要があります。
これまでのところ、IPおよび/またはMACアドレスベースの認証を認識しています。
HTTP Cookieを使用して認証を実装することは可能ですか? (多分サードパーティのCookieですか?)websenseはそれをどのように行いますか? ( cookie authentication を参照)
HTTP Cookieがプロキシ認証に使用できない場合、MACアドレス認証はこのことの業界標準ですか?
通常、プロキシ認証を実装する標準的な方法は、驚くべきことに プロキシ認証 です。
これは、一致する response ヘッダーと request ヘッダーのセットであり、ユーザーとプロキシの間で必要な認証を一緒に実装します。
これは通常、透過プロキシで使用され、ブラウザとプロキシの両方で十分にサポートされています。一部のプロキシはこれを異なる方法で実装します(たとえば、資格情報の検証方法など)が、ほとんどの場合、これがはるかに望ましいソリューションです。このソリューションには 非常にいくつかの欠点 があり、BlueCoatなどの標準HTTPを破壊する代替ソリューションにはかなりの数の問題があります。
ここで、プロキシがキャプティブポータルを実装することについて言及しましたが、whyについては言及しませんでした。認証フォームを実装するだけの場合は、組み込みのソリューションはないと考えて、ソリューションを変更し、標準のプロキシを使用して、必要な認証を定義することをお勧めします。独自のキャプティブポータルを構築するのは非常に難しいので、(経験から)多数の脆弱性にさらされる可能性があります。
キャプティブポータルを構築する他の理由がある場合-ランダムなサインアップ、支払いオプション、クレイジーな楽しみなど-おそらく複雑で、私たちはそれらに対処できます。それ以外の場合は XY問題 のようになります(実際の問題について尋ねるのではなく、ソリューションを想定してそれについて尋ねる場合...)
BlueCoatを透過プロキシとしてデプロイすると、Cookieサロゲートの概念を使用してユーザーを認証できます。これを機能させるために、使用されるコアメカニズムは、常に認証を要求する仮想URLへのリダイレクト(HTTP 401)です。これは、次のように実装されています。その上:
初回認証:
1。 UA(ユーザーエージェント)はGET /
をHost:www.example.com
に発行します
2。プロキシサーバーはGETをインターセプトし、仮想URLへのリダイレクト(302)と、要求された元のURLを含むクエリ文字列(例: 「http://virtualURL.com?QueryString
」
3。 UAは仮想URLへの接続を試みます
4。プロキシはHTTP 401で応答し、認証を要求します
5。 UAはステップ3と同じ要求を再発行しますが、認証資格情報を使用します
6。 UAは再びリダイレクトされ(302)、今回は元のURLにクエリ文字列がまだ添付されています(http://www.example.com?QueryString
)。また、virtualURLから来ているように見えるSET-COOKIE
があります(これは最初のもの以外のサイトへのリクエストで使用される)
7。 UAは元のURL +クエリ文字列に接続します。リクエストにクエリ文字列がまだあるため、プロキシは新しい302を発行します。今回はwww.example.com
に、SET-COOKIE
も含まれますが、今回はCookie example.comドメインから発行されたものとして動作します。
8。 UAはwww.example.com
に接続し、Cookieも受信して受け入れます。このCookieは、ユーザーが認証されたことをプロキシに通知します。
9。プロキシは、トランザクションを妨害しないように、UA要求を元のURLに転送してCookieを削除します。
後続のリクエストは次のようになります。
www.newsite.com
へのリクエスト、virtualURL?QueryString
へのリダイレクト、今回はvirtualURLドメインへのCookieがすでにあるため、401は不要であり、newsite.com?QueryString
、SET-COOKIE
への新しいリダイレクト新しいドメイン、元のURLにリダイレクトします。
同じ概念を使用して、それをプロキシサーバーに適合させることができると思います。