CloudGuard のSSO プロバイダとしてのShibboleth IDP の設定

ここでは、Shibboleth IDP でSSO をCloudGuardする方法について説明します。

主なステップは以下のとおりです。

  • CloudGuard SSO 設定でのShibboleth IDP の設定

  • CloudGuardをサービスプロバイダとしてShibboleth に追加します。

    • CloudGuardメタデータの追加

    • SP 設定の詳細(暗号化、シグネチャ) を微調整します。

    • CloudGuardへのアトリビュートの解放

    • メールをNameId としてマップする

CloudGuard SSO 設定

CloudGuardには次のパラメータが必要です。

  • AccountId - アカウントに名前を付ける識別子。通常、組織名(スペースなし) または数値を指定します。

    SSO ログインURL は、この識別子に基づいている必要があります。

  • Issuer - これは、IDP 設定で定義されている発行者です。通常、https://sso.myorg.com/idp/shibboleth形式のURL

  • IDP endpoint URL - 接続するメインSAML エンドポイント。通常はhttps://sso.myorg.com/idp/profile/SAML2/Redirect/SSOのようになります。

  • X.509 certificate - IDPのパブリックシグネチャ証明書。設定に応じて、idp-signing.crt などの名前が付けられます。

    -----BEGIN CERTIFICATE-----
    MIIDFDCCAfygAwIBAgIVAN3vv+b7KN5Se9m1RZsCllp/B/hdMA0GCSqGSIb3DQEB
    CwUAMBUxEzARBgNVBAMMCmlkcHRlc3RiZWQwHhcNMTUxMjExMDIyMDE0WhcNMzUx
    .. redacted...
    DHv3e4rwq3LznlqPw0GSd7xqNTdMDwNOWjkuOr3sGpWS8ms/ZHHXV1Vd22uPe70i
    s00xrv14zLifcc8oj5DYzOhYRifRXgHX
    -----END CERTIFICATE-----

新しいCloudGuard ユーザを登録し、 のSSO プロバイダとしてShibboleth IDP を設定します。

Shibboleth 設定

新しいSP メタデータの作成

ローカルメタデータファイルとしてSP の詳細(リレーパーティ) を指定します。

メタデータフォルダにcloudguard-metadata.xml という名前のファイルを作成し、次の設定を貼り付けます。

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
ID="_bf63813d70b5f63a1d2a3504dca89b5e268be651"
entityID="https://secure.dome9.com/">
<md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport">
<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsasha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
</md:Extensions>
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://secure.dome9.com/sso/saml/<YOUR_ACCOUNT_ID>" index="1"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>

注 - このファイルを編集し、CloudGuard設定で選択したのと同じアカウントID (accountId) を使用します。

新しいSP を参照する

conf/metadata-providers.xml にエントリを追加して、このメタデータファイルを参照します。

<MetadataProvider id="Dome9MDProvider" xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/dome9-metadata.xml"/>

(変数idp.home が正しく設定されていると仮定します。)そうでない場合は、絶対パスを使用できます)。

SP 構成を微調整する

CloudGuard SAML インプリメンテーションでは、シグネチャ付きアサーションが必要です(ただし、暗号化は必要ありません)。暗号化はHTTPS トランスポートによって提供されます)。

conf/relying-party.xml ファイルでこれらの詳細を設定します。このオーバーライドリストを検索します。

<!-- Container for any overrides you want to add. -->
<util:list id="shibboleth.RelyingPartyOverrides">

そして、この豆を加えます:

<bean parent="RelyingPartyByName" c:relyingPartyIds="https://secure.dome9.com/">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO" p:encryptAssertions="false"
p:signAssertions="true" p:postAuthenticationFlows="attribute-release" />
</list>
</property>
</bean>

出力は次のようになります。

<!-- Container for any overrides you want to add. -->
<util:list id="shibboleth.RelyingPartyOverrides">
<bean parent="RelyingPartyByName"
c:relyingPartyIds="https://secure.dome9.com/">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO" p:encryptAssertions="false"
p:signAssertions="true" p:postAuthenticationFlows="attribute-release" />
</list>
</property>
</bean>
... other SP configuration...
</util:list>

NameID 設定

CloudGuard は、NameId 項目がメールアドレスとして設定されることを想定しています。IDP へのリダイレクト要求中に自動的にネゴシエートされます。

設定にNameId ジェネレータが存在することを確認する必要があります。

ファイルconf/saml-nameid.xml を編集し、SAML2 NameIDGenerator が有効になっていること(コメントアウトされておらず、メールフィールドに正しくマッピングされていること) を確認します。

<!-- SAML 2 NameID Generation -->
<util:list id="shibboleth.SAML2NameIDGenerators">
<ref bean="shibboleth.SAML2TransientGenerator" />
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
p:attributeSourceIds="#{ {'mail'} }" />
</util:list>

注 - NameId が設定されていない場合、このメッセージがShibboleth ログに表示されることがあります。

Profile Action AddNameIDToSubjects:移植性のない識別子形式の使用を要求します。urn:oasis:names:tc:SAML:1.1:nameidformat:emailAddress

これは、ユーザのメールのソースフィールドがメールフィールドであることを前提としています。メールが別のフィールドにある場合は、そのメールをマッピングする必要があります。

アトリビュートをCloudGuard に解放します。

CloudGuard は最低限必要な権限を使用します。必要最小限のアクセス許可を付与するようにShiboleth を設定します。

このフェーズでは、唯一の要件はメールフィールドをエクスポートすることです(これはNameId にマップされます)。今後のフェーズでは、ユーザのダイナミックな作成とロールへの割り当てをサポートするための追加情報を渡します。

ファイルconf/attribute-filter.xmlを編集します。グループの最後(</afp:AttributeFilterPolicyGroup> より前の行) の前に、新しい子要素を<afp:AttributeFilterPolicyGroup> に追加します。

<!-- Release some attributes to Dome9. -->
<afp:AttributeFilterPolicy id="exposeAttributesToDome9">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="https://secure.dome9.com/" />
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="mail">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="surname">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="givenName">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>

これにより、以下が得られます。

<?xml version="1.0" encoding="UTF-8"?>
<afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
xmlns:afp="urn:mace:shibboleth:2.0:afp"
xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:afp
http://shibboleth.net/schema/idp/shibboleth-afp.xsd
urn:mace:shibboleth:2.0:afp:mf:basic
http://shibboleth.net/schema/idp/shibboleth-afp-mf-basic.xsd
urn:mace:shibboleth:2.0:afp:mf:saml
http://shibboleth.net/schema/idp/shibboleth-afp-mf-saml.xsd">
<!-- Release some attributes to Dome9. -->
<afp:AttributeFilterPolicy id="exposeAttributesToDome9">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="https://secure.dome9.com/" />
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="mail">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="surname">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="givenName">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>

設定を保存します。

  1. SSO にログインしていないことを確認します。

  2. CloudGuard SSO ログインにログインします(https://secure.dome9.com/sso/<your_account_id>)。

  3. IdP に正しくリダイレクトされていることを確認します。

  4. CloudGuard テストユーザのSSO 認証情報を入力し、SSO 同意を承認します(必要な場合)。

  5. CloudGuard ポータルに移動し、テストユーザID を使用して自動的にログインする必要があります。

トラブルシューティング

  • https://secure.dome9.com/sso/<MY ACCOUNT ID> のCloudGuard ログインページに移動し、セッションを記録します(Chrome F12 ツールを使用)(ログの保存の確認設定が有効)。

  • 発信元IDP に送信するリクエストCloudGuardを確認します。次のオンラインツールを使用して、SAML リクエストをデコードできます。https://idp.ssocircle.com/sso/toolbox/samlDecode.jsp

  • CloudGuard リクエストが意味がある場合は、Shibboleth ログの検査を続行します。

  • より効果的なデバッグ経験を得るには、conf/logback.xml でorg.opensaml.saml ロギングをDEBUG に設定して、Shibboleth でデバッグをオンにします。

  • Shibboleth ログのWARN またはERROR は、問題のある構成を示しています。

  • Shibboleth 起動シーケンスログを検査します。正常にロードされた新しいメタデータが表示されます。 /opt/shibboleth-idp/metadata/dome9-metadata.xml.

  • Shibboleth IDP からCloudGuard にSAML POST を検査します(ブラウザセッションの記録を再度行ってください)。オンラインツールを使用してデコードします。

  • IDP からCloudGuard へのSAML POST に意味がある場合(すべての予想されるアトリビュートが表示され、最も重要なのはSubject:NameId です。アサーションは署名されており、暗号化されていません)、CloudGuard監査証跡を検査します(非SSO CloudGuard管理者ユーザを使用)。

  • それでも問題がある場合は、Check Pointサポートに連絡し、サポートチケットを開いてください。ここでは、記録したすべての関連情報とREQUEST (リダイレクト) とPOST (レスポンス) を入力します。