At three hundred people, "who has access to the portal?" stops being a rhetorical question. Someone leaves on Friday, IT disables their domain account on Monday, and the account keeps working in five SaaS tools because it was created there separately, by hand. Six months later security asks for a list of live accounts and the only honest way to produce one is to open five admin panels and reconcile them manually.
SAML 2.0 SSO closes that gap. DTPulse becomes a service provider sitting next to your Identity Provider: the password is only ever typed into your IdP, and the portal receives a signed assertion about who just arrived. Disable the account upstream and portal access is gone the same second, with no separate step to remember.
What the employee sees
The sign-in page grows a "Continue with SSO" button. The employee types their work email, the portal resolves the company from the domain and hands them off to your IdP. From there it's your normal corporate login with whatever policies you run — password, second factor, conditional access, device posture. They come back already inside the portal.
DTPulse does not ask for its own TOTP code on an SSO sign-in. The second factor stays where IT manages it instead of being duplicated.
What the admin configures
The form lives in Admin → Settings and is ADMIN-only; HR does not have that section at all.
The top half is the service-provider metadata you copy into your IdP: Entity ID, ACS URL and a metadata URL. Each is specific to your company, each has a copy button, and the metadata endpoint is a plain URL if your IdP prefers to import rather than be typed into.
The bottom half is what you paste back from the IdP: its Entity ID, SSO URL, an optional SLO URL, and one or more X.509 certificates in PEM. Attribute mapping for email, first name and last name is available separately for IdPs that use non-standard names; left empty, the standard claim URIs and NameID are used. Finally, a default role for accounts created through SSO: USER, HR or ADMIN.
It is one form and one save. The real setup time depends on how quickly your IdP administrator can create the application on their side, not on the portal.
What happens on first sign-in
The account is provisioned just in time from the assertion — email, first name, last name, default role. Repeat sign-ins never duplicate anything: if an employee with that email already exists, the portal simply links them to the external identity.
Two checks run before anything is created. The email domain has to be on the company's domain list, so even a correctly signed assertion cannot mint an account on a domain you don't own. And headcount has to fit the plan limit: at the ceiling, a sign-in doesn't quietly create an extra record, it returns an explicit error the admin can act on.
After that the new person is in the ordinary flow: a card in the org chart, a department, a manager, a seat on the office map.
Secure by default
Assertion signing is mandatory and the interface deliberately offers no way to switch it off. IdP-initiated sign-in is off by default and has to be enabled on purpose. Every consumed assertion is recorded and a second use of the same one is rejected; for IdPs like ADFS that don't always emit an assertion ID, the identifier is derived from sessionIndex, inResponseTo or a hash of the response itself, so replay defence holds regardless.
Signature, conditions, the NotBefore / NotOnOrAfter window, Audience and Destination are all validated, with 60 seconds of clock skew allowed. The SP private key — needed only if you sign outgoing AuthnRequests — is stored AES-256-GCM encrypted and never returned by the API. The SSO URL is accepted over https only, and certificates must parse as PEM.
Every sign-in and every rejection lands in the audit log with a reason: audience mismatch, expired certificate, wrong domain, replay. That turns an incident review into five minutes instead of a day.
Certificates don't expire behind your back
A daily job reads the expiry date of each IdP certificate and emails the company's admins 30 days ahead of time. Multiple certificates can be stored at once, so a rotation is add-new, switch, remove-old — no maintenance window.
Whose time this saves
IT stops treating the portal as an exception to the access model. Provisioning and de-provisioning happen in the same place as for every other system.
Security gets a clear answer to "how is access revoked" and a log that shows who signed in, who was refused, and why.
New hires don't get a separate password or an invitation email. The account appears the moment they first sign in.
HR stops watching the employee list drift away from reality between personnel events.
Getting started
Add your email domains in settings, create a SAML application in your IdP, copy three fields across in each direction, test with one user, then flip the toggle for everyone.
SAML is configurable on every plan — the only ceiling is headcount. It matters most for self-hosted deployments: credentials never leave your perimeter, and the portal only ever sees a signed statement about identity, recorded in the same audit log as everything else.