Single sign-on with your identity provider

With single sign-on your people sign in to LogPulse through your own identity provider: Microsoft Entra ID, Okta, Google Workspace, Auth0, AD FS or any other OIDC or SAML 2.0 provider. Your provider handles passwords, multi-factor authentication and conditional access, and removing someone there stops their next sign-in to LogPulse.

Single sign-on is part of the Enterprise plan and is being rolled out. Contact us to enable it for your organization.

How it works

An owner of your LogPulse organization sets it up under Settings, Security, Single sign-on, in three steps: verify your email domains, connect your identity provider, and choose who gets in. Admins can see the settings but not change them.

People then sign in with Continue with SSO and their work email address. LogPulse finds your identity provider from the domain of the address, so nobody needs to know which provider you use.

1. Verify your domains

Your organization proves that it owns its email domain with a DNS TXT record. Only addresses in verified domains can sign in through your identity provider. Subdomains are included: verifying company.com also covers eu.company.com.

Add the domain, for example company.com.
LogPulse shows a TXT record name (_logpulse-verification.company.com) and a value (logpulse-domain-verification=…). Create that record at your DNS provider.
Click Verify now. DNS changes can take a while; LogPulse keeps checking every hour for 48 hours and emails the owners when the domain is verified.

A domain can be verified by one organization only. Free email domains (gmail.com, outlook.com and the like) and public suffixes cannot be claimed. Keep the record in place: LogPulse checks it every week and tells the owners when it disappears. The domain stays verified, but support needs the record to settle any dispute about the domain.

Is your domain already verified by another organization? Contact support. We settle it on proof of DNS ownership and never tell you which organization it was.

2. Connect your identity provider

Register LogPulse as an application in your identity provider, then enter its details in LogPulse and save. After saving, LogPulse shows the values to enter in your provider: the redirect URI for OIDC, or the ACS URL, SP entity ID and metadata URL for SAML.

LogPulse asks only for the scopes openid, profile and email. It needs the email address of each user in the token or assertion. The client secret is stored encrypted and is never shown again. Put its expiry date in your calendar: an expired secret stops every SSO sign-in at once.

Microsoft Entra ID

In the Microsoft Entra admin center, go to App registrations, New registration. Name it LogPulse and choose Accounts in this organizational directory only. Leave the redirect URI empty for now.
Under Certificates & secrets, create a client secret. Copy its value and note the expiry date.
In LogPulse, choose OpenID Connect. Issuer: https://login.microsoftonline.com/<your Directory (tenant) ID>/v2.0. Client ID: the Application (client) ID. Client secret: the value from step 2. Save.
Copy the redirect URI LogPulse now shows. In Entra, under Authentication, Add a platform, Web, paste it as the redirect URI.
Under Token configuration, add the optional claim email to the ID token, so that every user's address reaches LogPulse.
Optional: in Enterprise applications, LogPulse, Properties, set Assignment required to Yes and assign the users or groups who may use LogPulse.

Use your own tenant in the issuer. LogPulse refuses common, organizations and consumers, because those would let any Microsoft tenant in. This is different from Sign in with Microsoft on the sign-in page, which works for every organization without any setup.

Okta

In the Okta admin console, go to Applications, Create App Integration, OIDC - OpenID Connect, Web Application.
Keep the grant type Authorization Code. Leave the sign-in redirect URI for later and assign the people or groups who may use LogPulse.
In LogPulse, choose OpenID Connect. Issuer: https://<your org>.okta.com (or your custom authorization server). Enter the client ID and client secret, and save.
Copy the redirect URI from LogPulse into Sign-in redirect URIs in Okta.

Google Workspace

In the Google Cloud console of your Workspace organization, set up the OAuth consent screen with user type Internal, so only your Workspace accounts can sign in.
Under Credentials, create an OAuth client ID of type Web application.
In LogPulse, choose OpenID Connect. Issuer: https://accounts.google.com. Enter the client ID and secret, and save.
Copy the redirect URI from LogPulse into Authorized redirect URIs of the OAuth client.

Other OIDC providers

Any provider with OpenID Connect discovery works: Auth0, Keycloak, Ping, OneLogin and others. Use the issuer URL whose /.well-known/openid-configuration your provider publishes, create a confidential web client with the authorization code flow, allow the scopes openid, profile and email, and make sure the email claim is filled. LogPulse uses PKCE.

SAML 2.0 (AD FS and others)

For SAML, enter the entity ID of your identity provider and either its metadata XML or its single sign-on URL and signing certificate. After saving, give your provider the values LogPulse shows:

ACS URL (reply URL): where your provider posts the assertion.
SP entity ID (audience): identifies LogPulse in the assertion.
SP metadata URL: for providers that import LogPulse's metadata.

Send a persistent NameID and the user's email address as an attribute (email, or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress). Assertions must be signed with SHA-256 or stronger; SHA-1 is refused. Sign-in always starts from LogPulse: IdP-initiated sign-in is off.

When the connection is saved and a domain is verified, click Test sign-in. You sign in through your provider and come back to the settings, which then say the connection works.

3. Choose who gets in, and how

Create members on first sign-in: someone in a verified domain who signs in through your provider for the first time becomes a member with the role you choose (Viewer by default). Change roles afterwards under Members.
Allow members outside your domains: consultants and suppliers with an address elsewhere keep their access when this is on. Turn it off to admit only accounts in your verified domains.
Break-glass owners: up to two owners who can still sign in with their password and a second factor (passkey or authenticator app) when your identity provider is down. Every such sign-in is logged and emailed to all owners.
Require SSO: every account in your verified domains can only sign in through your identity provider. Password sign-in, password reset, new password accounts, Google, GitHub, Microsoft and passkey sign-in are refused for those accounts. Sessions that did not come through your provider end right away, and SSO sessions last at most 12 hours.

You can turn it on once a domain is verified, the connection is saved, you have signed in through it yourself (Test sign-in), your own address is in a verified domain and at least one break-glass owner is chosen. The screen lists whatever is still missing and how many accounts it affects.

While Require SSO is on, the connection cannot be changed or removed: a broken configuration would lock everyone out at once. Turn it off, change and test the connection, then turn it on again.

Signing in

On the sign-in page, choose Continue with SSO and enter your work email address. You go to your identity provider and come back signed in. The first time, LogPulse creates your account and, if your organization allows it, makes you a member.

Already have a LogPulse account with the same address? It is connected to your identity provider on your first SSO sign-in, and you get an email about it. Your account's address must be confirmed for this.

Signed out after 12 hours? That is the maximum for an SSO session. Sign in again with Continue with SSO; with an active session at your provider, that takes one click.

Errors and what to do

When a sign-in is refused, the sign-in page explains why. The code is in the address bar after error=.

Code	What it means	What to do
sso_required	Your organization requires single sign-on for your address.	Use Continue with SSO with your work email address.
sso_not_configured	No verified domain or connection for this address.	Check the address, or ask your LogPulse owner to finish the setup.
sso_email_domain_mismatch	Your provider sent an address outside the organization's verified domains.	Ask your administrator to check the email claim or attribute the provider sends.
sso_seat_limit	The organization has no free seats.	Ask an owner to free a seat or upgrade the plan.
sso_outside_member_blocked	The organization admits only accounts in its own domains.	Ask an owner if you need access.
sso_session_expired	The 12 hours of your SSO session are up.	Sign in again with Continue with SSO.
account not linked	An account with this address exists but its address is not confirmed.	Confirm the address from the email LogPulse sent, or ask support.

Security and responsibilities

What LogPulse checks: an identity provider can only sign in addresses in its organization's verified domains, so a misconfigured or hostile provider cannot take over anyone else's account. Client secrets and SAML keys are stored encrypted. SAML responses must be signed, are checked against the request that started them and cannot be replayed.

Every change to the single sign-on settings, every SSO sign-in and every refused sign-in is written to your organization's audit log (index _audit). Changes, break-glass sign-ins and a LogPulse support override are also emailed to all owners.

What stays with your identity provider: multi-factor authentication, conditional access and removing people who leave. Until SCIM provisioning is available, someone removed from your provider can no longer sign in, and any open session ends within 12 hours. Their personal access tokens keep working until you remove them as a member, so remove leavers in LogPulse too.

Questions

How is this different from Sign in with Microsoft?

Sign in with Microsoft on the sign-in page works for anyone with a work or school Microsoft account, without setup. Single sign-on is your organization's own connection: you choose the provider, you can require it and you control who becomes a member.

Can we connect more than one identity provider?

One connection per organization. One connection can serve several verified domains.

Do you support SCIM and group-to-role mapping?

Not yet. Both are planned. Until then, members get the default role on first sign-in and you manage roles in LogPulse.

What if our identity provider is down and Require SSO is on?

Your break-glass owners sign in with their password and second factor and can turn Require SSO off. If they cannot, contact LogPulse support: after checking who is asking, support can turn it off, and every owner is told.

Does it work in the mobile app?

Single sign-on in the iPhone app is on its way. Until then, people whose organization requires SSO use LogPulse in the browser.

Does it work on a dedicated environment?

Yes. You set it up in the same way on your own environment; the URLs LogPulse shows then use your environment's address.