Smartabase

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.

It does appear to activate the settings instantly so any changes made are in place immediately.

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

From a SSO perspective,they do not support SP-initiated SSO, but rather hack it into appearing to work by requiring you to supply a URL to the application that will trigger IdP-initiated SSO. The URL for this is supplied in their user interface. There are some odd details about this that are discussed in the Notes section at the bottom of this page.

On the response side, all the standard behaviors work as long as the properties are configured as I documented above (e.g. turning off the assertion signing requirement).

While they claim in various bits of documentation to support logout, I saw no indication of this in practice, and the application doesn't seem to do anything useful when the logout link is clicked if SSO is enabled. It wasn't a matter of settings being wrong unless there's a magic "do this" setting I missed. I got no response from the vendor about it.

Example Shibboleth Configuration

Required Profile Configurations

SAML2.SSO

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.

The application supposedly only supports email-based identification of users.

Attribute Requirements

It does not support SAML Attributes.

Other Considerations

The lack of support for SP-initiated SSO also manifests in some questionable choices around use of RelayState to support routing users into the different portions of their application, and it doesn't really work well. They support two URL slots, one for "main" and one for "mobile". Incredibly, "mobile" doesn't even really mean their mobile application, but a mobile version of their web site, which they expect users of a mobile device are going to try and get to somehow.

They (mis)use RelayState in IdP-initiated SSO to force you tell them which portion of the system to land the user in, between "main", "admin", "mobile", and "builder". That works if users start with links you provide for those options, but users starting at the admin site will end up at the main user site if you give it that URL as the primary SSO link to use, so they just don't understand how badly this all works and don't seem to care I suppose.

Actual enablement of SSO for users is based on their role, but because it's IdP-initiated at its core, you can test yourself while in a non-SSO rule by just triggering the IdP directly and it works.