[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[upki-fed:282] Re: [upki-fed:280] Re: [upki-fed:279] Re: SSLアクセラレータ環境



お世話になっております。
寺口です。

分かりやすく丁寧なご説明有難うございます。

> # SPとIdPが同一ホストという状況では理解が難しくなってしまう
> # かと思いますので、一般的な状況を仮定します。
そうなのです。同じホストでIdPとSPを立ち上げている事が、
状況をややこしくしたのかもしれません。
IdPとSPを分けた想定で、以下の説明を読むと、
IdP、SP、メタデータの関係がすっきりして、
非常に分かりやすく、素直に理解できました。

現在、他SPからのテスト接続も正常に動作し、
順調に本番稼動に向かっております。

今後ともよろしくお願いいたします。


2010年11月19日19:35 Takeshi NISHIMURA <xxxxxxx@xxxxxxxxx>:
> NIIの西村と申します。
> よろしくお願いします。
>
> 通常Shibboleth 2.x(SAML2)を使っている上でSSLアクセラレータに
> アクセスするのは利用者のブラウザのみとなりますし、それはSAML
> とは別個に考えることができますので、アクセラレータのあるなし
> に関係なく、3-1〜3-3の設定は必要になります。
> 逆に言うと、http:のような信頼性のない通信路で「誰それが認証さ
> れた」という情報を改ざんされることなくやりとりしなければなり
> ませんので、そのような場面でこそIdP/SPの証明書および秘密鍵の
> 設定が不可欠になります。
>
>> 3-1.SPの設定
>>     shibboleth2.xml
>>     <CredentialResolver type="File" key="sp-key.pem"
>> certificate="sp-cert.pem" />
>>         ↓
>>     <CredentialResolver type="File"
>>                         key="/opt/shibboleth-idp/credentials/idp.key"
>>                         certificate="/opt/shibboleth-idp/credentials/idp.crt" />
>
> SPの設定にIdPの秘密鍵(idp.key)が必要になることはありえません。
> …と思ったのですが、このテストは同じホストでIdPとSPを立ち上げて
> 行っているのですね。つまり「SPの証明書」と「IdPの証明書」が
> 同じものであるという特殊な状況と理解しました。
>
>> とくに、3の設定で、SPの鍵、IdPの鍵、メタデータ内の証明書が、
>> いつ、何のために使われているのか気になります。
>
> # SPとIdPが同一ホストという状況では理解が難しくなってしまう
> # かと思いますので、一般的な状況を仮定します。
>
> SAML2のプロトコルの本質は
> 1. SPがIdPに対して認証要求を行う
> 2. IdPがその認証要求に対して認証応答を返す
> と単純化できます。認証応答には「確かに認証された」という情報や属性
> 情報など(アサーション)が含まれますが、詳細は省きます。
> これらは、通信路上での盗聴・改ざんを防ぐため、適切に暗号化・署名
> されなければなりません。
>
> 一方、証明書(正確に言うと公開鍵暗号)を使って暗号化を行うには、
> 通信相手の証明書を知っていなければなりません。これを伝達する手段が
> 「メタデータ(フェデレーションメタデータ)」になります。メタデータ上に
> は全てのIdP/SPが載っており、その証明書も含まれているため、例えばSPが
> IdPに対して認証要求(という名のデータ)を送るときに相手のIdPの証明書
> を探し出すことができます。
> 署名検証の場合も同様です。
>
> 以上から、それぞれの鍵および証明書の役割は以下のようになります。
> [前提]「メタデータ内の証明書」は、通信相手に自分の証明書を伝達する役割
> - SPにて認証要求に署名を行うのは、「SPの秘密鍵」の役割
> - IdPにて、認証要求に施された署名の検証を行うのは、「SPの証明書」の役割
>  (メタデータによってIdPはSPの証明書を知ることができる)
> * IdPにて認証応答に暗号化を行うのは、「SPの証明書」の役割
>  (メタデータによってIdPはSPの証明書を知ることができる)
> * IdPにて認証応答に署名を行うのは、「IdPの秘密鍵」の役割
> * SPにて、認証応答に施された署名の検証を行うのは、「IdPの証明書」の役割
>  (メタデータによってSPはIdPの証明書を知ることができる)
> * SPにて認証応答を復号するのは、「SPの秘密鍵」の役割
>
> 「誰が」「何をするときに」「何を用いる」を明確にしていけば、それほど
> 難しいものではないと思います。
>
> ちなみに、上記で"*"で書いているものはShibboleth 2.xのデフォルト動作、
> "-"で書いているものはオプションで指定できるものです。
> 対称でなくてアレなのですが、「認証要求を暗号化する」というオプションは
> 存在しないようです…
>
>
> (2010/11/18 17:28), kohei teraguchi wrote:
>> お世話になっております。
>> 寺口です。
>>
>> SSLアクセラレータ環境での設定について報告いたします。
>>
>> 1.動作確認環境
>>     OS:Red Hat Enterprise Linux Server release 5.2 (Tikanga)
>>     Webサーバ:Apache/2.2.3
>>     shibbolethSP:shibboleth-2.3.1-1.3
>>     shibbolethIdP:shibboleth-identityprovider-2.2.0
>>     ドメイン:test.researchmap.jp
>>
>>
>> 2.ログイン画面の表示
>> 2-1.apacheの設定変更
>>     ServerName test.researchmap.jp
>>         ↓
>>     ServerName https://test.researchmap.jp
>>
>>     https://spaces.internet2.edu/display/SHIB/SPNoSSL
>>     では、ポート番号の指定とUseCanonicalNameをOnに設定していますが、
>>     無くても動作いたしました。
>>
>> 2-2.apache−tomcat連携の設定変更
>>     <Connector port="8009" protocol="AJP/1.3"  redirectPort="8443"
>>                enableLookups="false"
>>                request.tomcatAuthentication="false"
>>                address="127.0.0.1" />
>>         ↓
>>     <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
>>                enableLookups="false"
>>                proxyPort="443" scheme="https"
>>                request.tomcatAuthentication="false"
>>                address="127.0.0.1" />
>>
>>     参考:
>>     http://groups.google.com/group/shibboleth-users/browse_thread/thread/3247848f1087777c/a2bc1ce79fb1f428?lnk=gst&q=SAML+message+intended+destination+endpoint#a2bc1ce79fb1f428
>>
>>
>> 3.認証処理
>> 3-1.背景、現象
>>     SSLアクセラレータを通したWEBサーバへのリクエストは全てhttpになるため、
>>     SP(shibboleth2.xml)、及び、IdP(relying-party.xml)に設定されている
>>     秘密鍵と証明書は必要ないと判断し設定を行っていなかったが、
>>     設定を行わないと、ログイン時にエラーが発生する。
>>
>> 3-1.SPの設定
>>     shibboleth2.xml
>>     <CredentialResolver type="File" key="sp-key.pem"
>> certificate="sp-cert.pem" />
>>         ↓
>>     <CredentialResolver type="File"
>>                         key="/opt/shibboleth-idp/credentials/idp.key"
>>                         certificate="/opt/shibboleth-idp/credentials/idp.crt" />
>>
>> 3-2.IdPの設定
>>     relying-party.xml
>>     <security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
>>         <security:PrivateKey>/opt/shibboleth-idp/credentials/idp.key</security:PrivateKey>
>>         <security:Certificate>/opt/shibboleth-idp/credentials/idp.crt</security:Certificate>
>>     </security:Credential>
>>
>>     デフォルトのままで変更なし。
>>
>> 3-3.鍵設定
>>     /opt/shibboleth-idp/credentials/idp.keyにtest.researchmap.jpの秘密鍵を設定
>>     /opt/shibboleth-idp/credentials/idp.crtにtest.researchmap.jpの証明書を設定
>>
>>
>> 以上の設定で、tomcat再起動、apache再読込みを行ったところ動作いたしました。
>>
>>
>> 2-1の設定については、ServerNameを変更しているため、
>> WEBアプリケーション側に影響が出る可能性があるかと思いますので、
>> 今後、調査したいと思います。
>>
>> また、2、3の設定がどのように影響して動作するようになったのか、
>> いまいち理解しておりません。。。。
>>
>> とくに、3の設定で、SPの鍵、IdPの鍵、メタデータ内の証明書が、
>> いつ、何のために使われているのか気になります。
>> 想定では、
>> ・SPの秘密鍵はSAMLの情報を暗号化する際に使用している。
>> ・SPの証明書はSP本人確認のためのデジタル署名に使用している。
>> ・IdPの秘密鍵はSAMLの情報を暗号化する際に使用している。
>> ・IdPの証明書はIdP本人確認のためのデジタル署名に使用している。
>> ・メタデータ内の証明書はSAMLの情報を複合する際に使用している。
>> の様な感じかと思っております。
>>
>> その辺りの情報等、詳しい方がいらっしゃいましたらご教授いただければ幸いです。
>
> --
> 西村健
> 国立情報学研究所 TEL:03-4212-2720
>