SSO is used for authentication (username and password). ShotFlow acts as a Service Provider (SP); whereas, a client’s systems are Identity Providers (IdP). Okta and ForgeRock are examples of IdP, which manage their users internally.
(We don’t currently support Active Directory; no syncing between systems with AD as a system of record.)
Users that are added via SSO will NOT receive a notification email from ShotFlow. SSO users should be notified via their SSO provider or client IT that they have been granted access to ShotFlow.
FAQ (Frequently Asked Questions)
Which Protocols are supported for SSO?
ShotFlow supports SAML - 2.0 protocol at this time.
Support for SSO (IdP-initiated, SP-initiated)?
ShotFlow supports both IdP and SP-initiated authentication.
Support for Single Logout (SLO)?
ShotFlow does not support SLO at this time.
How to Provide a metadata file?
After configuring the Service Provider section within ShotFlow you can optionally open the Metadata URL which will result in a download of the metadata for the account. Please note, that the file should be renamed and “.xml” should be appended to the filename. Optionally, this URL can be provided to the client as some IdP supports this however this is on a per-client basis depending on the IdP they are using.
Supported SSO Bindings (POST/Redirect)
ShotFlow utilizes POST for login. SSO logout if implemented in the future utilizes redirect.
What is Entity/Connection ID?
After configuring the Service Provider section within ShotFlow the SSO endpoint is the entity id.
Assertion Consumer Service URL (if Metadata is not available)
After configuring the Service Provider section within ShotFlow the SSO endpoint the assertion consumer service URL (also known as Audience URI).
Required SAML attributes/Primary Identifier
(EmployeeID/email/NetworkID)
This is configured in the Attributes section. The primary identifier is the email address. The development team suggests standardizing the attributes across clients for ease of use however it’s not a requirement. That being said, email, first name, and last name are required attributes in the SAML assertion. Groups are optional however must be configured in conjunction with Applications/Roles.
What are the plans to authorize users to the application?
Example: Reading data from SAML token (ie: AD groups, Div/Loc, Dept):
This is optional, and if used requires the Groups in the Settings section as well as the Application/Roles section to be configured within ShotFlow.
Does the Service Provider support encryption of nameid (optional) (Yes/No):
ShotFlow requires encrypted metadata/assertions, a ShotFlow certificate is provided.
Point of contact: Business and Technical contact information (email/phone):
ShotFlow Analyst configuring SSO contact details
If this is a SaaS or 3rd party vendor product and it is the SP (Service Provider), will the client or the vendor be doing SP Service Provider configuration?
SSO is built into our platform/API and does not require any SP configuration from the client/vendor as this is handled internally by ShotFlow.
What is the SP signing certificate requirement?
ShotFlow requires encrypted metadata/assertions, a ShotFlow certificate is provided.
How will users be managed in the Application for provisioning and de-provisioning?
Is there an API? If, yes - REST API, SCIM, or other?
Provisioning is handled by ShotFlow utilizing groups provided in the SAML attributes (if provided). De-provisioning has not been implemented however this would be done VIA ShotFlow’s RestAPI.