What SSO standards do we support at Grip?
At Grip, we support the following standards for Single-Sign-On
- SAML 2 standard
- OpenID Connect standard
- OAuth 2.0 standard
For all SSO we do at Grip, we only support and do Single-Sign-On but not Single-Sign-Off.
Apart from SAML 2, proprietary integrations can be discussed and implemented at added cost.
What SSO providers can we integrate with?
For SAML 2, we have successfully integrated with:
- Auth0 (www.auth0.com)
- Keycloak (www.keycloak.org)
For proprietary integrations, we have successfully done so for:
- Comexposium
- Dimedis
- Freeman
- Messe München
What do we need from clients to enable SSO?
In all SSO integration, the client must have a Branded Application. Events running in the Grip App cannot have SSO enabled. The SSO Identity Provider must also guarantee that the authenticated user is also authorized to use Grip for the specific application/event. This is done by having a 1-to-1 mapping of our Thing's registration id or email with the response from the SSO Identity Provider. We do not support compressed SAML.
For SAML 2 SSO, we require that the client support the following:
- SAML Requests sent from Grip to any Identity Provider is not encrypted
- All signatures are signed with rsa-sha256 hashing
Requirements needed from Clients for SAML 2 SSO Standard:
- The SAML2 IdP signing and encryption certificate (if any)
- IdP metadata. Can be an XML or a publicly accessible URL
- The SAML2 IdP Issuer name
- The login endpoint (to send users to)
- The SAML2 IdP logout url (optional)
- A description of the SAML Response’s XML (so that we know how to map their data to a grip thing registration id)
- Test users on the Client’s system that are linked to Grip things
Information Client gets from Grip:
- Grip Application ID
- Container ID
- Our SP Metadata endpoint : https://api.intros.at/sso/saml2/application/<APP ID>/sp/metadata.xml
- Our SAML Assertion endpoint: https://api.intros.at/sso/saml2/application/<APP ID>/sp/assert
Requirements needed from Clients for OpenID Connect Standard:
- Test Login Account Details (test account linked to a Grip User Type)
- OIDC Client ID
- OIDC Client Secret
- OIDC Authorization URL
- OIDC Token URL
- OIDC User Profile URL
- User Profile Data to Thing identifier (how to look up a User and match it to a Grip "Thing" User Type)
Information Clients get from Grip:
- Grip Application ID
- Container ID
For proprietary integrations, we will require documentation from the client before advising on the feasibility of integration and requirements.
Important Considerations for all SSO Integrations
- Grip will never become the IdP (An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO)
- The client must have a Branded Application with Grip.
- Events running in the Grip App cannot have SSO enabled.
- The SSO Identity Provider must also guarantee that the authenticated user is also authorized to use Grip for the specific application/event. This is done by having a 1-to-1 mapping of our Thing's registration id or email with the response from the SSO Identity Provider.
What features are not available when an application has SSO enabled?
Applications, and all the events within them, with SSO enabled, will have the following key difference:
- Users no longer manage passwords on Grip
- Users can create Teams (if Teams is enabled) but cannot invite users to their Teams. Team members can only be added via registration, relationships or Dashboard users.
- Users cannot enable Event Signups through Grip and must come via a standard registration integration.