Kainos SMART
This information was last reviewed in September, 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 Kainos SMART
The official SAML documentation doesn't appear to be online but presumably would be provided to any customer. It was mostly accurate.
Identity Provider Metadata
The application has a very minimal config interface that is limited to cut and paste of an IdP's metadata file. It accepted a production Shibboleth IdP metadata file and of course ignores the signature. I don't know yet if it honors validUntil so I left it in to see what happens. That's the sum total of options related to IdP behavior except for specifying how to pull the user's email address, addressed later on.
Service Provider Metadata
They have a bit of an odd model where you have to check the enable SSO box and save that first to get it to generate a key and then provide a button to obtain the SP's metadata. The problem is that guarantees users get locked out because it auto-enables all their accounts for SSO and only leaves the admin doing the work as the exception. So you'll have to work around that if your system is already live.
Aside from that, it's no problem to obtain the metadata from it (assuming you're good with blind trust in your browser/TLS) and it's mostly correct with two significant errors, a bunch of improper <NameIDFormat> elements and the fact that it contains the WantAssertionsSigned flag. Both should be removed.
Profile Requirements
It supports default behavior, encryption, etc. It does sign its requests and relies on the HTTP-Binding for its requests. I asked them to stop signing them, don't know if they will.
I saw no sign of logout support, SAML or proprietary.
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.
Required Profile Configurations
SAML2.SSO
Account Provisioning
The accounts have to be in place with an appropriate email address as the user ID. Individual accounts can be toggled as SSO or not, and you would normally leave the IdP admin's account as non-SSO for back door access.
NameID Requirements
It does support use of the NameID but I did not use that option.
Attribute Requirements
It supports extraction of a SAML Attribute to obtain an email address to match up with the user accounts. It does not allow any other form of user account identification. I was able to use the standard mail attribute (urn:oid:0.9.2342.19200300.100.1.3).
Other Considerations
Just to reinforce, you can't set this up until you turn SSO on, so don't do this in a live system. Get somebody else to test it for you so you can leave your admin account as a non-SSO account to maintain the settings.