Single Sign-On
Single Sign-On (SSO) allows your User Accounts to connect to DonorPoint using your (or ‘their’ in the case of Community users) existing login services. When a User Account that is logged into their company domain accesses a protected DonorPoint page, they are automatically logged in with the appropriate DonorPoint User Account. Similarly when someone accesses a protected DonorPoint page set up for a company’s SSO services, and they are not logged into the company’s services, they are redirected to the company domain login page rather than the DonorPoint login page. Having ‘one less password’ without sacrificing security improves the user experience of DonorPoint services and the donor experience on protected forms. This also workplace campaign accounts the ability to comply more closely with your workplace partners’ security protocols.
DonorPoint communicates with third-party services via the industry-standard SAML protocol, version 2.0. Any indentity provider product is compatible with DonorPoint, and DonorPoint has demonstrated integrations with the following platforms:
- Microsoft ADFS
- Microsoft AzureAD
- Oracle Identity Manager
- Shibboleth
- Okta
SSO setup and management involves the following
- SSO configuration of a company’s SAML Identity Provider service metadata into DonorPoint
- Input of DonorPoint’s SAML Service Provider metadata into the company’s Identity Provider
Setup for your organization’s access to the DonorPoint admin application via SSO is separate from setting up a workplace’s access to DonorPoint forms via SSO. The two are independent and one can be set up without the other.
Management of User Accounts, User Groups, Roles and Permissions for SSO User Accounts are the same as for User Accounts that will use DonorPoint login passwords. Creation, activation, import and deactivation operations for User Accounts using SSO to login to DonorPoint are the same for User Accounts using DonorPoint passwords to login. Furthermore DonorPoint passwords may still be used by SSO accounts to login to DonorPoint. Note that DonorPoint support prefixing the names returned by a third-party identity service to ensure uniqueness of usernames on the DonorPoint platform. For example if an identity service returns a numerical account id, DonorPoint can prefix it with a unique assigned to that identity service to look up the corresponding DonorPoint username.
DonorPoint SSO Links
Once SSO is setup using the steps below, you can access the applications as follows:
- If you set up the admin access via SSO, your users can log into the DonorPoint admin application at ‘donorpoint.{your domain}’.
- Workplaces that you have set up for SSO will access their forms via the links listed on the
Sharing
tab for each form. Note that if you have configured a subdomain on your domain to link to DonorPoint forms, this subdomain will be in the long form of the URL.
DonorPoint admin Domain
To use SSO to access the DonorPoint admin/ application, you need to create a CNAME record in your DNS that maps the subdomain ‘donorpoint’ on your domain to ‘production.gobigriver.com’:
CNAME | donorpoint | production.gobigriver.com |
Note that if you use additional DNS servers in your organization, each one of them will require this record.
** There will be a delay between your DNS setup and DonorPoint adding your subdomain to our SSL certificate to enable https connections. Please notify DonorPoint at help@donorpoint.com when setting or changing your subdomain to expedite the SSL certificate process. **
NameId Matching
DonorPoint identified the user in an SSO login by matching the name identifier provided by the identity provider with the username of a DonorPoint user account. Usernames in DonorPoint are defined when created in the admin application or imported (e.g. via an employee file). The nameId sent by the identity proivided can be configured by most identity management systems, and in most cases will default to the login name used by users of that identity provider. Best practive in DonorPoint is to map the nameId to the email address provided in the employee file. Consult your identity provider documentation for how to do change the nameId to another user parameter to match usernames provided to DonorPoint. In cases where company policy prevents an email address being used as the SAML identifier, you can configure DonorPoint to find the DonorPoint UserAccount name from another attribute returned by the identity provider by setting the onelogin.saml2.idp.nameIdAttribute
property, for example:
onelogin.saml2.idp.nameIdAttribute=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Usernames in DonorPoint are unique across all accounts. When an organization’s user names are likely to have collisions with other usernames, an organization-specific prefix can be added to the username craeted or imported into DonorPoint to prevent the collision. That prefix is set as the value of the onelogin.saml2.idp.nameIdPrefix
property for the organziation. For example if the organziation must use its internal standard for employee ids for security reasons that are purely numeric (‘00001’, ‘00002’, …). You can set the onelogin.saml2.idp.nameIdPrefx` as such:
onelogin.saml2.idp.nameIdPrefix = ThatOrg
And then prefix all usernames in the organization with that prefix:
username | … |
---|---|
ThatOrg001 | … |
ThatOrg002 | … |
… | … |
Single Logout
Currently DonorPoint does not support single logout (SLO). When User Accounts log out of the third-party identity provider, they remain logged into DonorPoint and need to log out of DonorPoint separately. This is generally regarded as acceptable practice, as after logging out, accessing the application would automatically log back in under SSO. Also the notion of logging out of the application can be confused with logging out of the identity provider. Note that DonorPoint automatically logs out after having been idle for 15 minutes, as require for PCI-DSS compliance.
Bypassing SSO
SSO can be bypassed and the DonorPoint password-based login used by adding “normallogin=true” to the page’s URL. Note that when accessing the page from the View button on cards in Community list in admin, or from the Preview link in the Community page editor, the normallogin parameter will be added by defalt.
SSO Configuration – DonorPoint to Third-party Identity Provider (IdP)
DonorPoint’s metadata for an Account can be accessed at the link:
https://production.gobigriver.com/admin/metadata.seam?accountId=#{accountId}
where #{accountId} is the Account’s database id.
For Organizations the link is:
https://production.gobigriver.com/engage/metadata.seam?organizationId=#{organizationId}
where #{organizationId} is the Organization’s database id.
Note that you can set up an organization link as well as an account link for your own organization, for example to enable non-DonorPoint users in your organization to access giving forms via SSO.
Note that these links can be found on the Security tab for an Organization or Users for an Account record in DonorPoint. The IdP should be configured to send over the identity with nameId corresponding to the usernames in DonorPoint.
SSO Configuration – Third-Party Identity Provider to DonorPoint
DonorPoint allows you to import the metadata from Identity Providers using a simple wizard. From the Secrurity tab on Organization records, or the Users tab on Accounts, there is a list of registered SAML Identity Providers. To import Identity Provider metadata, select the Upload button and select the metadata file. DonorPoint will scan the file and set the proper metadata fields.
DonorPoint supports SSO access to multiple applications, selected on the import popup:
- /engage - the Community module forms
- /admin - the DonorPoint application This selection is limited to Identity Providers added to your Account. For Organizations (i.e. workplace fundraising partners), /engage is the only relevant application.
Metadata can be updated by editing the metadata entry on the Organzation or Account record, and re-importing an updated metadata file.
Additional metadata properties can be set on the Properties field of the popup. See Options and Troubleshooting below.
Legacy SSO Configuration – Third-Party Identity Provider to DonorPoint
Previously DonorPoint accepted Identity Provider metadata entered on an Account or Organization’s Properties textarea on the Integration tab for the Account or Organization. This is fully supported in the current version of the SSO module, and legacy properties can be maintained using the instructions in this section. However DonorPoint metadata from the link listed above will follow the new format. Legacy SSO integrations requiring a re-import of the DonorPoint metadata will require creating a new integration using the process described above. Any Identity Provider metadata imported using the file import described above will supersede any legacy metadata.
IdP EntityID - Identifier of the IdP entity (must be a URI)
Example:
onelogin.saml2.idp.entityid=https://idp.ssocircle.com
Single Sign-On Service URL
SSO endpoint info of the IdP. (Authentication Request protocol)
URL Target of the IdP where the SP will send the Authentication Request Message
This endpoint supports the HTTP-Redirect binding only
Example
onelogin.saml2.idp.single_sign_on_service.url=https://idp.ssocircle.com:443/sso/SSORedirect/metaAlias/publicidp
Identity Provider Public X.509 Certificate
Example
onelogin.saml2.idp.x509cert=MIID…
Signature Algorithm (optional, defaults to RSA SHA-256)
Example
onelogin.saml2.security.signature_algorithm = http://www.w3.org/2000/09/xmldsig#rsa-sha256
Options and Troubleshooting
In the case where usernames have an organization prefix to maintain uniqueness in DonorPoint, an organization prefix can be specified.
onelogin.saml2.idp.nameIdPrefix = DA
Optional force new login after timeouts on server side
onelogin.saml2.forceAuthn = true
ADFS 2019 requires the following to avoid going through the login screen when already logged in
onelogin.saml2.security.requested_authncontext =