Page tree
Skip to end of metadata
Go to start of metadata

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

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

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

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:

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

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


And add this bean:


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

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


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

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


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

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


  • No labels