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

この記事は、JASIG CASサーバーのインストールと設定の実用的なガイドを目的としています。 シングルサインオン（SSO）が何であるかを説明することを目標に設定しなかったので、この概念に慣れていない場合は、まずWikipediaとTechtargetポータルをチェックしてください。 また、SpringとMavenの経験があることをお勧めします。

記事は3つのパートで構成されます。 最初に、CASを選択した理由とそのプロトコルの機能について簡単に説明します。 記事の残りの部分では、サーブレットコンテナの構成から始まり、外部フォームからの承認や資格情報のハッシュ化などの重要な問題の解決まで、承認サービスの設定に専念します。

JASIG CASを選ぶ理由

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

• JAVAテクノロジースタック。 CASは、Springを使用してJAVAで完全に記述されています。 アセンブリには、Mavenが使用されます。
• オープンソース
• 複数のLDAP実装のサポート。
• アクティブなコミュニティ。 快適なJASIGポータルとwikiには、ネット上に多くの記事があります 。
• すべての一般的なプラットフォームのクライアント。 詳細はこちらをご覧ください。
• さまざまな認証方法のサポート。
• 頻繁なリリース。
• セットアップが比較的簡単。 この記事のおかげで、本当にシンプルで理解しやすくなることを願っています。

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

仕組み

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

凡例

• クライアントはユーザーのブラウザです。 CASクライアントと混同しないでください。
• アプリケーションは、CASクライアントを搭載し、承認にCASサーバーを使用するアプリケーションの1つです。
• CAS -SSOサービスがデプロイされたサーバーまたはクラスター。
• ST-サービスチケット。 これは、サービスにアクセスするためのクライアント資格情報として使用される文字列です。 クライアントは、CASサーバーに提供された資格情報とサービス識別子への応答としてそれを受け取ります。
• TGT （チケット許可チケット）およびTGC（チケット許可Cookie）。 TGTは、クライアントの承認済み状態のインジケータとして機能する文字列です。 承認後、クライアントの資格情報を置き換えます。 TGT値は、クライアント認証が成功した後、CASサーバーによって設定されたTGCに保存されます。
• LT （ログインチケット）。 クライアント資格情報とともに渡される文字列。 資格情報の再処理を防止するために使用されます。
• SAML （セキュリティアサーションマークアップ言語）は、OASISによって開発されたXMLベースの言語です。 詳細は、コミュニティのWebサイトで見つけることができます。

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接続を確立できるように、キーのインポートが必要です。 キーをインポートする前に、

• 正しいバージョンのJAVAを使用しています。 複数のバージョンがインストールされている場合、問題が発生する可能性があります。
• Keytoolと、認可されたサービスの開始に使用するJavaのcascertsパスを使用します。
• リポジトリにキーをインポートする権限があります。

その結果、次のメッセージが表示されるはずです。

 Certificate was added to keystore.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージが正しく表示されないか、何らかのテキストが続く場合は、何か間違ったことをしていて、キーがインポートされていない可能性が高いことを意味します。

戦闘環境では、 ThawteやVerisignなどの有名なCAのいずれかによって提供されたキーを使用する可能性が最も高くなります。 この場合、キーはpkcs＃7またはx.509形式であり、最初にpkcs＃12形式に変換する必要があります。

たとえば、X.509（Base64）形式の証明書の場合、次の一連の手順を実行する必要があります。

• すべての中間証明書を1つのファイルに接着します。 証明書を最初に配置し、次に中間チェーン全体を順番に配置する必要があります。
• OpenSSLを使用して目的の形式に変換します。
  
  

   openssl pkcs12 -export —in your.crt —inkey your.key —out your.p12 -name «cas»
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• キーペアが正しく作成されていることを確認します
  
  

   keytool —keystore your.p12 -storetype pkcs12 —list
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• 最後のステップ-キーペアに基づいてキーストアを作成する
  
  

   keytool -importkeystore -deststorepass 12345678 -destkeypass 12345678 -destkeystore ssoServer.jks -srckeystore your.p12 -srcstoretype PKCS12 -srcstorepass 12345678 -alias cas
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

パブリック証明書ストアのデフォルトは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サーバーを構成および構築する方法を説明します。