ReviewSnap
This information was last reviewed in April, 2019, 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.
ReviewSnap is a pretty standard self-managed SP. Their official documentation was at https://www.reviewsnap.com/support-article-2/setting-saml-authentication/ at time of authoring.
They also have a presence in InCommon that has a different technical back-end (a Shibboleth SP). This document speaks to the non-InCommon version.
Identity Provider Metadata
The web UI has an interface under Settings → Authentication and SSO, that include toggle switches for enabling password, SAML, or LDAP. The SAML Configure panel has the usual options:
- https://idp.example.org/idp/profile/SAML2/Redirect/SSO
- PEM blob. They have a field for fingerprint that would probably also work but no real reason to bother.
- The SP's own name, which you can set. Easy to just use "https://app.reviewsnap.com" for consistency.
- You can use the NameID field, or make life easier and give it a SAML Attribute name, which Shibboleth is better at.
- This is populated for you with the right URL for your instance, see SP metadata below.
- This is populated for you with the right URL for your instance, see SP metadata below.
Service Provider Metadata
They do not provide any SP metadata; it has to be manually pieced together from their GUI. I have a key on record for them for encryption support, but I actually don't recall how I got it. It may be in their documentation, or was provided out of band when I conversed with them.
An example that includes the key we have on record:
Profile Requirements
The SAML SSO profile behavior is standard and relies on signed responses and supports encryption.
Logout is not supported.
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 application assumes provisioning of matching accounts in advance.
NameID Requirements
They do support use of a NameID, but I haven't used or tested it. All indications are any Format would work, and it's just looking for a matching value.
Attribute Requirements
They support only a single Attribute to match application username against, and we've used this to match on an employee ID number.