Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This information was last reviewed in November, 2018, by Scott Cantor

Change Log:

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

This is a page for documenting Shibboleth integration with Smartabase

They do have (very poor) documentation at https://profilersports.screenstepslive.com/s/builder/m/590/l/872043-single-sign-on but there are significant details wrong or missing, and I had to make several round trips with their support staff to get it working.

Identity Provider Metadata

The application has a web interface that provides some fields to load the details into in a very odd and horrific fashion. It requires most of the core settings be supplied in a comma-delimited multi-line dump of low level, renamed OneLogin SAML library properties. I suspect they renamed them to avoid a customer being able to subvert some of the internal settings, but it would be fascinating to test that in a car-wreck sort of fashion.

Even better, half the fields don't seem to actually work or end up used, but it's always questionable to guess in these cases. The properties I used are below but most of the URLs and logout details really shouldn't matter for reasons I'll get into later.

You will need to generate a keypair for the SP yourself and then supply them here. The hidden trick is it has to be a PKCS#8 formatted private key, which you can get from a normal RSA key file using OpenSSL.

The base64 material for the three blobs has to be flattened to one line.

saml2.idp.single_sign_on_service.url,https://idp.example.org/idp/profile/SAML2/Redirect/SSO
saml2.idp.single_logout_service.url,https://idp.example.org/idp/profile/SAML2/Redirect/SLO
saml2.security.want_assertions_signed,false
saml2.idp.entityid,<your entityID>
saml2.idp.single_logout_service.response.url,https://example.smartabase.com/example/SAMLsso/logout
saml2.sp.entityid,https://example.smartabase.com/example/main
saml2.idp.single_sign_on_service.binding,urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
saml2.idp.single_logout_service.binding,urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
saml2.sp.privatekey,<PKCS#8 private key on one line>
saml2.idp.x509cert,<base64 cert on one line>
saml2.security.want_assertions_encrypted,true
saml2.sp.x509cert,<base64 cert on one line>

Service Provider Metadata

Metadata has to be hand-generated, and most of their documentation about this is wrong. I'm using something more or less like the below example.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://example.smartabase.com/instance/main">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>
<your generated SP cert>
		  </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:AssertionConsumerService index="1" isDefault="true"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://example.smartabase.com/instance/SAMLsso/acs"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Profile Requirements

Encryption isn't supported so has to be disabled (or the idp.encryption.optional property tutrned on). There weren't any other special requirements.

SAML Logout does appear to work.

Example Shibboleth Configuration

Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.

Excerpt from relying-party.xml 
<!-- Container for any overrides you want to add. -->
 
<util:list id="shibboleth.RelyingPartyOverrides">
 
    <!-- other overrides... -->
 
    <bean p:id="example.DisableEncryption" parent="RelyingPartyByName">
        <constructor-arg name="relyingPartyIds">
            <list>
                <value>your ProofPoint entityID</value>
            </list>
        </constructor-arg>
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                <bean parent="SAML2.Logout" />
            </list>
        </property>
    </bean>
 
</util:list>

Required Profile Configurations

SAML2.SSO

SAML2.Logout (if desired)

Account Provisioning

The accounts have to be in place with an appropriate email address as the user ID.

NameID Requirements

It requires use of the NameID. I doubt it checks the Format, but I used the standard urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress Format to carry the data and triggered that via an <md:NameIDFormat> element in the SP's metadata.

Attribute Requirements

It does not support SAML ATtributes.

Other Considerations

There's a Test feature on the Advanced tab of the SAML dialog.

Enabling SAML apparently blocks normal password-based login, so subsequent maintenance has to be carefully coordinated in case something breaks.

  • No labels