JASIG CASを使用した単一認証(SSO)。 パート1


この記事は、JASIG CASサーバーのインストールと設定の実用的なガイドを目的としています。 シングルサインオン(SSO)が何であるかを説明することを目標に設定しなかったので、この概念に慣れていない場合は、まずWikipediaTechtargetポータルをチェックしてください。 また、SpringとMavenの経験があることをお勧めします。
記事は3つのパートで構成されます。 最初に、CASを選択した理由とそのプロトコルの機能について簡単に説明します。 記事の残りの部分では、サーブレットコンテナの構成から始まり、外部フォームからの承認や資格情報のハッシュ化などの重要な問題の解決まで、承認サービスの設定に専念します。

JASIG CASを選ぶ理由


単一の承認という考え方には多くの実装がありますが、JASIG CASがすべての点で対応するものより優れているとは言えませんが、それでも多くの理由で解決しました。

同じ基準でSSO用のプラットフォームを選択する場合、CASはまさにあなたが探しているものです。

仕組み


私たちは、2番目のバージョンのプロトコルで動作するSSOサービスであるCASの基盤として採用しました。 このプロトコルの詳細は、JASIGポータルで見つけることができます 。 以下は、CASでの成功した承認のプロセスの図です。 JASIGポータルでそのようなスキームを見つけられませんでしたが、プロセスを理解するのに役立つはずです。

凡例





SSOサーバーへのすべてのリクエストはHTTPS経由でなければならないことに注意してください。 これはプロトコルの要件ではありませんが、これがないとユーザー資格情報のセキュリティを確保できません。
プロトコルのもう1つの重要な機能は、ST + TGT、CAS値の確認中に、許可されたサービスにインストールされたクライアントが元の要求を停止し、新しい要求を作成することです。 つまり 現時点では、CASサーバーのクライアントはユーザーのブラウザではなく、承認されたサービスです。 つまり、HTTPS接続を作成するには、サービスを適切に構成する必要があります。 これを行う方法は、少し後で説明します。 元のリクエストの処理は、検証が完了した後にのみ再開されます。

サーバー、キー、問題


サーブレットコンテナとして、Tomcatを選択しました。 ユーザーに関する情報はopenLDAPに保存され、アプリケーションのCASクライアントとして最も頻繁に使用されるのは公式のJavaクライアントです。 執筆時点では、 最新バージョンは3.1でした。
SSOの設定は、サーブレットコンテナの設定から始まります。 テスト環境と戦闘環境では、これは少し異なります。
テスト環境では、 keytoolユーティリティを使用して、自己署名証明書を作成する必要があります。 Keytoolは、JDKに含まれている標準ユーティリティです。
keytool -genkey -alias cas -keypass 12345678 -keystore ssoServer.jks -storepass 12345678 -dname «cn=localhost, ou=webdev, o=ourOrganisation, c=RU» -validity=365 

その結果、キーストアssoServer.jksとプライベートキーとパブリックキーのペアを作成します。 これで、キーストアから公開鍵をエクスポートできます
 keytool -export -alias cas -file casServerPublic.cer -keystore ssoServer.jks -storepass 12345678 

そして、単一の承認に参加するすべてのサービスのために、それを信頼証明書ストアにインポートします。 PCでは、コマンドは次のようになります。
 keytool -import -alias cas -file %PATH_TO%casServerPublic.cer -keypass 12345678 -keystore JAVA_HOME/jre/lib/security/cacerts cacerts -storepass changeit 

このようなMacの場合:
 # /Library/Java/Home/bin/keytool -import -alias cas -file %PATH_TO_CERTIFICATE%/casServerPublic.cer -keypass 12345678 -keystore /Library/Java/Home/lib/security/cacerts -storepass changeit 

許可されたサービスがCASとのHTTPS接続を確立できるように、キーのインポートが必要です。 キーをインポートする前に、

その結果、次のメッセージが表示されるはずです。
 Certificate was added to keystore. 

メッセージが正しく表示されないか、何らかのテキストが続く場合は、何か間違ったことをしていて、キーがインポートされていない可能性が高いことを意味します。
戦闘環境では、 ThawteVerisignなどの有名なCAのいずれかによって提供されたキーを使用する可能性が最も高くなります。 この場合、キーはpkcs#7またはx.509形式であり、最初にpkcs#12形式に変換する必要があります。
たとえば、X.509(Base64)形式の証明書の場合、次の一連の手順を実行する必要があります。

パブリック証明書ストアのデフォルトはchangeitです。 戦闘環境では、それを変更する必要があります。
CASが配置されるTomcatのコネクタを構成することは残ります。 これを行うには、次のように、%TOMCAT-HOME%/ conf / server.xmlファイルにコネクタの説明を追加します。
 <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keyAlias="cas" keystoreFile="%PATH_TO%.ssoServer.jks" keystorePass="12345678" /> 

ドキュメントのページでコネクタの設定に関する詳細を読むことができます
HTTP戦闘環境では、server.xmlからのコネクタをさらに削除するのが最適です。

今回がすべてです。 次のパートでは、CASサーバーを構成および構築する方法を説明します。

Source: https://habr.com/ru/post/J142407/


All Articles