app.us.honeyhive.ai) so your users sign in with their work accounts. After setup, users enter their work email at sign-in and are redirected to your IdP automatically.
HoneyHive configures its side of the connection for you. This page covers what you set up in your IdP and what you send HoneyHive. For self-hosted deployments, see Identity Provider instead.
To start, Contact us or reach out to your account team.
Choose a protocol
HoneyHive supports SAML 2.0 and OpenID Connect (OIDC). Use whichever your IdP supports best.
Complete the shared setup first, then follow Set up SAML or Set up OIDC.
Shared setup
1
List your email domains
List every domain your users sign in with. Matching is exact, so list subdomains such as
eng.acme.com separately from acme.com.- Each domain can belong to only one HoneyHive organization.
- Public domains such as
gmail.comoryahoo.comnever grant organization membership.
2
Send HoneyHive your details
Send HoneyHive your chosen protocol, your email domains, and your HoneyHive organization name if it already exists.HoneyHive replies with the values to enter in your IdP: the ACS URL and entity ID for SAML, or the redirect URI for OIDC.
Set up SAML
1
Create a SAML application
In your IdP, create a SAML 2.0 application for HoneyHive and enter the values HoneyHive sent you:
2
Configure the NameID and attributes
Set the
NameID to the user’s email address and add these attributes. Send the email attribute even though NameID is also the email, so the address reaches HoneyHive as the user’s email. The attribute names are claim identifiers, not URLs to visit.Sign the SAML response or assertion.
3
Assign users
Assign the users or groups who should have access to the application. HoneyHive grants no access to anyone your IdP does not authenticate.
4
Send HoneyHive your IdP details
Send one of the following:
- Your IdP’s SAML metadata URL (preferred).
- Your IdP’s sign-in URL, issuer (IdP entity ID), and X.509 signing certificate.
Set up OIDC
1
Create an OIDC web application
In your IdP, create an OIDC web application for HoneyHive with these settings:
Generate a client secret.
2
Assign users
Assign the users or groups who should have access to the application. HoneyHive grants no access to anyone your IdP does not authenticate.
3
Send HoneyHive your IdP details
The values you send depend on your IdP. Send the client secret through a secure channel.
- Okta
- Microsoft Entra ID
- Other OIDC providers
Test sign-in
- Open app.us.honeyhive.ai and enter an assigned user’s work email.
- Confirm you are redirected to your IdP and back to HoneyHive.
- Confirm the user appears as a member of your organization, not only signed in to HoneyHive. If not, see Troubleshooting.
User attributes
Both protocols must provide these values for each user:
HoneyHive identifies each account by email address, compared case-insensitively:
- Use a stable, unique email per person. Two IdP users with the same email sign in to the same HoneyHive account. Do not send shared mailbox addresses.
- Email changes create a new account. A user whose email changes signs in as a new user with no memberships. Contact us to migrate memberships.
NameIDformat does not affect account identity. HoneyHive matches accounts on email, so a transientNameIDdoes not split a user’s account.- Send the address users type at sign-in. The email in the assertion or token must use one of your organization’s domains.
- Sign in through SSO, not a password account. A HoneyHive username-and-password account with your domain is not added to your organization automatically.
Group attributes
On multi-tenant SaaS, HoneyHive does not read IdP group claims. Access within the organization is managed in HoneyHive:- Users who match your email domains join the organization as Org Member on first sign-in.
- Admins add users to workspaces and projects and assign roles. See Inviting Teammates and Roles.
- To limit who can reach HoneyHive, restrict assignment of the HoneyHive application in your IdP.