Configure Shibboleth IDP as SSO provider for Dome9

In this topic:

    This guide will take you through the steps to configure Dome9 SS) with Shibboleth IDP.

    The outline of the steps are:

    • Configure Shibboleth IDP details in Dome9 SSO config

    • Adding Dome9 as a service provider to Shibboleth:

      • Adding Dome9 metadata

      • Fine tuning the SP configuration details (encryption,signing...)

      • Releasing attributes to Dome9

      • Mapping the email as the NameId

    Dome9 SSO Configuration

    Dome9 requires 4 parameters:

    • AccountId - an identifier you wish to name your account. Usually should be your org name (no spaces) or a number.

      Your SSO login URL should be based on this identifier

    • Issuer - this is the issuer as defined in your IDP config. Usually a URL in the format https://sso.myorg.com/idp/shibboleth

    • IDP endpoint URL - the main SAML endpoint to connect. Usually something like https://sso.myorg.com/idp/profile/SAML2/Redirect/SSO

    • X.509 certificate - the public signing certificate of your IDP. Depending on your config - could be named something like idp-signing.crt .Looks like

      PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

      -----BEGIN CERTIFICATE-----

      MIIDFDCCAfygAwIBAgIVAN3vv+b7KN5Se9m1RZsCllp/B/hdMA0GCSqGSIb3DQEB

      CwUAMBUxEzARBgNVBAMMCmlkcHRlc3RiZWQwHhcNMTUxMjExMDIyMDE0WhcNMzUx

      .. redacted...

      DHv3e4rwq3LznlqPw0GSd7xqNTdMDwNOWjkuOr3sGpWS8ms/ZHHXV1Vd22uPe70i

      s00xrv14zLifcc8oj5DYzOhYRifRXgHX

      -----END CERTIFICATE-----

    Create a test SSO user in Dome9 system

    Create a new Dome9 user. Make sure this user has SSO enabled in the Dome9 system and that you have SSO login credentials for this user.

    Shibboleth Configuration

    Creating a new SP metadata

    Provide the SP details (the relay party) as a local metadata file. For that:

    Create a file named: dome9-metadata.xml in metadata folder and paste this configuration:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <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>

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    IMPORTANT:

    DO NOT FORGET to edit this file and use the same Account Identifier (accountId) you chose in the Dome9 configuration!!!

    Referencing the new SP

    Reference this metadata file by adding to conf/metadata-providers.xml an entry:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <MetadataProvider id="Dome9MDProvider" xsi:type="FilesystemMetadataProvider"

    metadataFile="%{idp.home}/metadata/dome9-metadata.xml"/>

    (we assume the variable idp.home is configured correctly. Otherwise you can use an absolute path)

    Fine tune the SP configuration

    Dome9 SAML implementation requires signed assertions (But not encrypted. Encryption is provided by the HTTPS transport).

    Weʼll configure these details in the conf/relying-party.xml file. Search for this override list:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <!-- Container for any overrides you want to add. -->

    <util:list id="shibboleth.RelyingPartyOverrides">

    And add this bean:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <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>

    The Output should be something like:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <!-- 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 Configuration

    Dome9 expects to have a NameId field in the form of email address. It is automatically negotiated during the redirect request to the IDP.

    You'll need to verify that such a NameId generator exists in your configuration.

    For that please review the file conf/saml-nameid.xml

    Verify that the SAML2 NameIDGenerator is enabled (not commented out, and correctly mapping the mail field):

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <!-- 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>

    Note

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    Note 1:

    If you fail to do so you'll see something like this in your shibboleth log:

    Profile Action AddNameIDToSubjects: Request specified use of an

    unsupportable identifier format: urn:oasis:names:tc:SAML:1.1:nameidformat:emailAddress

    Note 2:

    This assumes that the source field for user's email is the mail field. If the email is present in a different field , then you'll need to map that one.

    Releasing the attributes to Dome9

    Dome9 believes and practices least privilege. As your users attributes might contain information that should not be exposed outside of your org we'll define the permitted attributes.

    At this phase the only requirement is to export the mail field (which will be mapped to NameId). In future phases we'll pass additional info to support dynamic creation of users and assignment to roles.

    We'll edit the conf/attribute-filter.xml file. We'll add a new child element to <afp:AttributeFilterPolicyGroup> element. We recommend to add this node just before the end of the group (line before </afp:AttributeFilterPolicyGroup>)

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <!-- 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>

    The End result should be something like:

    PROBLEM TABLE: Import has tried to automatically correct the problem structure. Please check content.

    <?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>

    Test the configuration

    • First, verify you are not logged in to your SSO

    • Login to your Dome9 SSO login (https://secure.dome9.com/sso/<your_account_id>)

    • Verify that you are correctly redirected to your IdP

    • Fill in the SSO credentials of the test Dome9 user and approve SSO consent (if needed)

    • You should be directed to the Dome9 portal and automatically logged in with the test user identity.

    Troubleshooting

    • Navigate to Dome9 login page at https://secure.dome9.com/sso/<MY ACCOUNT ID> and record (using Chrome F12 tools) the session (verify preserve logs setting is enabled)

    • Check the request Dome9 sends to Shibboleth IDP. You can decode the SAML request by using the online tool at : https://idp.ssocircle.com/sso/toolbox/samlDecode.jsp

    • If Dome9 request makes sense, continue to inspect Shibboleth logs.

    • To have a more effective debugging experience, turn on debugging in Shibboleth by setting org.opensaml.saml logging up to DEBUG in conf/logback.xml

    • Any WARN or ERROR in Shibboleth logs are an indication of a problematic config.

    • Inspect the Shibboleth startup sequence log. you should see New metadata successfully loaded for '/opt/shibboleth-idp/metadata/dome9-metadata.xml'

    • Inspect the SAML POST from Shibbolth IDP to Dome9 (again be recording the browser session). Decode it using the online tool.

    • If the SAML POST from IDP to Dome9 makes sense (you see all the expected attributes and most importantly the Subject:NameId,

      assertion is signed and not encrypted) then inspect the Dome9 audit trail (using a non SSO Dome9 admin user)

    • If got so far - contact Dome9 support at support@dome9.com, provide all relevant information and the REQUEST (redirect) and POST (response) you recorded.