[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[upki-fed:281] Re: [upki-fed:280] Re: [upki-fed:279] Re: SSLアクセラレータ環境
- Subject: [upki-fed:281] Re: [upki-fed:280] Re: [upki-fed:279] Re: SSLアクセラレータ環境
- Date: Fri, 19 Nov 2010 19:35:02 +0900
- From: 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