IdP, SP, DS に関する設定・運用・カスタマイズの各種情報についてまとめるページです。
目次
「技術ガイド > IdPセッティング > サーバ証明書の設定 > Back-Channelの設定」のSOAP設定でのclientAuthに設定する値がtrueから want に変更されています。本家 の情報も更新されていますので、Tomcatの設定ファイルserver.xmlを合わせて修正することをおすすめいたします。
Back-ChannelでSPからクライアント認証を受け付けるときに、クライアント証明書のExtenededKeyUsageにclientAuth(TLS Web Client Authentication)なしの証明書が用いられる可能性を考慮して設定を行なうことを推奨します。例えば、UPKIのサーバ証明書プロジェクトで発行されたサーバ証明書には、通常はclientAuth(TLS Web Client Authentication)がありません。
SPが下記の証明書を用いてBack-Channel接続を行ってきた場合にIdPがSPのクライアント認証を受け付けずにエラーとする実装があるようです。
$ openssl x509 -in sp-certificate.pem -noout -text | grep -A 1 'X509v3 Extended Key Usage:' X509v3 Extended Key Usage: TLS Web Server Authentication |
IdPから複数台のLDAPサーバの情報を参照するために使用するLDAPプロキシサーバ設定方法を資料にまとめました。各LDAPサーバとLDAPプロキシ間はLDAPS接続またはStartTLS接続をするものとします。詳細はPDF資料をご参照ください。
プロキシサーバを構築する際、ログイン画面で入力するID(Shibboleth内部ではprincipalと表現されます)について、同一のIDが複数のLDAPツリー上に存在しないことを確認してください。そうでなければ属性取得で問題が発生します。uidがこの条件を満たさない場合は、メールアドレスや学籍番号・教職員番号等を使うことを検討してください。 |
内容の異なる複数のLDAPツリーを横断的に検索するlogin.configの例はShibboleth Wiki:IdPAuthUserPassの"Stacking Login Modules"の項にあります。この場合、attribute-resolver.xmlでは2つのLDAP DataConnectorを定義し両方をDependencyに記述してください。
前項と同様、同一のIDが2つのLDAPツリー上に存在すると問題になりますので、uidがこの条件を満たさない場合は他の属性をID(principal)として使うようにしてください。 |
Embedded DSは、ブラウザの表示言語設定を反映して表示する言語を選びますが、特定の言語で表示したい場合の方法が下記に記載されてます。
学認参加のSPで特例として学認外のIdPをDSのリストに表示させるときの方法を記載します。
<SessionInitiator type="Chaining" Location="/DS" isDefault="true" id="DS"> <SessionInitiator type="SAML2" template="bindingTemplate.html"/> <SessionInitiator type="Shib1"/> - <SessionInitiator type="SAMLDS" URL="https://ds.gakunin.nii.ac.jp/WAYF"/> + <SessionInitiator type="Form" template="discoveryTemplate.html"/> </SessionInitiator> |
<MetadataProvider type="XML" file="additional_idp-metadata.xml"/> |
Back-Channel時にSPの証明書を用いてクライアント認証が行なわれることを想定して、ExtenedKeyUsageにclietAuth(TLS Web Client Authentication)を含めたサーバ証明書(もしくはExtendedKeyUsage自体が存在しないサーバ証明書)を用いることを推奨します。
$ openssl x509 -in sp-certificate.pem -noout -text | grep -A 1 'X509v3 Extended Key Usage:' X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication |
Back-Channelを用いて通信を行なうときに下記の証明書を用いた場合にはSPのクライアント認証が受け付けられずにIdPでエラーとする実装があるようです。
$ openssl x509 -in sp-certificate.pem -noout -text | grep -A 1 'X509v3 Extended Key Usage:' X509v3 Extended Key Usage: TLS Web Server Authentication |
Apacheの設定で require valid-user
を設定し、そのコンテンツにアクセスした時点でDSへリダイレクトされる、というのが学認における通常のフローかと思いますが、Apacheの設定に以下を追加すればこれが有効な範囲ではDSを経由せずに指定したIdPに直接リダイレクトします。
ShibRequestSetting entityID https://idp.example.ac.jp/idp/shibboleth
この他、以下のようなURLにアクセスさせることで、指定したIdPで認証させた後に指定したURLに遷移させることが可能です。
entityID
の部分で(%エンコードされていて分かりにくいですが)、リダイレクトさせたいIdPのentityIDを指定します。
target
には、認証成功後にリダイレクトする先のSP上のURLを指定します。
後者のURL中の"/DS"の部分は、shibboleth2.xmlで<SessionInitiator>要素を追加していない場合は"/Login"となります。 |
後者のURLにアクセスすると、SPセッションがすでに存在するかどうかに関わらずIdPに遷移します。IdPにてセッションが存在する場合はそのままSPに戻ります。認証成功後はSPのセッションは上書きされます。 |
Shibboleth SP 2.5より requireLogoutWith
が実装されました。 requireLogoutWith
では指定されたURL(通常はShibbolethのログアウトURLを指定)に遷移したのちに、元のページの戻るといった処理が自動的に行なわれます。
Shibboleth認証になっているパス(例えば /secure
)の中にWebアプリケーションのログアウト処理のページを用意します。ログアウト処理ページは仮に /secure/logout
とします。
$ cat /etc/httpd/conf.d/shib.conf (...略...) <Location /secure> AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user </Location> |
Webアプリケーションのログアウト処理ページ /secure/logout
に対して次のApacheの設定を追加すると requireLogoutWith
に指定されている /Shibboleth.sso/Logout
にてShibbolethセッションの破棄と /secure/logout
によるWebアプリケーションのログアウト処理が一連の動作として行なわれます。
<Location /secure/logout> require shibboleth ShibRequestSetting requireSession false ShibRequestSetting requireLogoutWith "/Shibboleth.sso/Logout" </Location> |
requireLogoutWith
に関する詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings をご参照ください。
SP 2.5.0では |
Shibboleth SP 2.5よりAttribute Checker Handlerが実装されました。同じくShibboleth SP 2.5からの機能であるsessionHookと合わせて利用することで、IdPから必要な属性が渡されているかチェックすることができます。ApplicationDefaultsの属性としてsessionHookを設定し、Sessionsの末尾にAttribute Checker Handlerを追加することでこの機能を利用できます。
NativeSPHandlerのページに倣い、SPでeduPersonPrincipalNameとdisplayNameの属性を必須とする場合の具体的な書き方を例示します。
<ApplicationDefaults id="default" policyId="default" entityID="https://sp.example.ac.jp/shibboleth-sp" REMOTE_USER="eppn persistent-id targeted-id" - signing="false" encryption="false"> + signing="false" encryption="false" sessionHook="/Shibboleth.sso/AttrChecker"> |
<Sessions> (...略...) <!-- Checks for required attribute(s) before login completes. --> <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" attributes="eppn displayName" flushSession="true"/> </Sessions> |
<Sessions> (...略...) <!-- Checks for required attribute(s) before login completes. --> <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" flushSession="true"> <AND> <Rule require="eppn"/> <Rule require="displayName"/> </AND> </Handler> </Sessions> |
<Sessions> (...略...) <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" flushSession="true"> <OR> <Rule require="eppn"/> <Rule require="displayName"/> </OR> </Handler> </Sessions> |
チェック対象の eppn
や displayName
といった属性名は /etc/shibboleth/attribute-map.xml
で定義されている内容に従って記述する必要があります。
この他に template="attrChecker.html"
に template="/var/www/html/Error.html"
のようなローカルのファイルを指定することで、Attribute Checkerによって表示されるエラーページを変更することも可能です。
Attribute Checker Handlerに関する詳細は https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPHandler#NativeSPHandler-AttributeCheckerHandlerVersion25andAbove をご参照ください。
CentOS 5標準のphpパッケージはPHP 5.1系であるため、GakuNinDSの https://ds.example.ac.jp/WAYF/IDProviders.json にアクセスすると下記のエラーが出力されます。
Fatal error: Call to undefined function json_encode() in /var/www/html/GakuNinDS/WAYF on line 668 |
このエラーはPHP 5.1に関数json_encode()が存在しないために出力されるものです。json_encode()はPHP 5.2以降でサポートされていますので、CentOS 5のパッケージとして提供されているphp53パッケージ(PHP 5.3)を用いることで解決します。
CentOS 5のphp53パッケージやCentOS 6のphpパッケージなど、PHP 5.3以降を使用しているマシンでGakuNinDSを動かすときには、httpdのエラーログに下記の警告が出力されることがあります。
\[Fri Mar 09 15:26:17 2012\] \[error\] \[client xxx.xxx.xxx.xxx\] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead in /var/www/html/GakuNinDS/functions.php on line 484, referer: <span class="nolink">https://sp.exapmle.com/</span>
上記の警告が出力されていてもGakuNinDSの動作には問題ありませんが、下記のように/etc/php.iniにてdate.timezoneを定義することでこの警告は出力されなくなります。
--- php.ini 2012/06/18 08:12:14 1.1 +++ php.ini 2012/06/18 08:19:26 @@ -943,7 +943,7 @@ [Date] ; Defines the default timezone used by the date functions ; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone -;date.timezone = +date.timezone = "Asia/Tokyo" ; http://www.php.net/manual/en/datetime.configuration.php#ini.date.default-latitude ;date.default_latitude = 31.7667 |