Single sign-on,
institutional.

Identity broker

WorkOS — SOC 2 Type II and ISO 27001 certified.

Protocols

SAML 2.0 and OpenID Connect (OIDC).

Identity providers

Microsoft Entra ID (Azure AD), Okta, Google Workspace, OneLogin, PingFederate, ADFS, Shibboleth / InCommon, JumpCloud, and any generic SAML 2.0 or OIDC provider.

Integration time

One to two business weeks, with the critical path almost always on the institutional IdP side.

Cost

Included with institutional licenses. No additional SSO fee.

Data flow

Authentication only. CSR does not receive or store credentials; your IdP returns a signed assertion about the user.

Certified Secure Researcher uses WorkOS as its identity broker for institutional single sign-on. WorkOS maintains a per-institution Connection that terminates the SAML or OIDC handshake and presents a normalized user profile to CSR.

Relying party

The Service Provider your IdP configures against is WorkOS, not CSR directly. This is the same integration pattern used by thousands of SaaS applications and is well-understood by campus IT teams.

Isolation

Your IdP metadata is registered inside a WorkOS Organization created specifically for your institution. No other customer shares your connection, ACS URL, or certificates.

Credential handling

CSR never sees the user's password and has no ability to reset, rotate, or enumerate institutional credentials.

Session

When a user signs in, WorkOS validates the signed IdP assertion, then issues CSR a short-lived authentication profile containing the attributes mapped in section 05.

1. Step 01

   Kick-off

   Your identity administrator submits the connection request form at the bottom of this page — institution legal name, email domain(s), preferred protocol, and primary IdP admin contacts. That kicks off our side. Prefer email? support@certifiedsecureresearcher.com.

2. Step 02

   CSR creates your Organization

   We provision a dedicated WorkOS Organization and a staging Connection, and reply within two business days with an onboarding packet containing your connection-specific Service Provider metadata.

3. Step 03

   Your IdP team configures the SP

   Using the SP metadata we provide, your identity team creates a new application or relying-party trust on the IdP side. Entra ID, Okta, Shibboleth, and ADFS all accept SP metadata XML directly, which is the fastest path.

4. Step 04

   You return IdP metadata

   Send us your IdP metadata XML, or the equivalent values: IdP entity ID and SSO endpoint URL and X.509 signing certificate. For OIDC, send the discovery URL, client ID, and client secret through a secure channel — we can provide a one-time-use upload link.

5. Step 05

   Attribute mapping and round-trip test

   We wire up attribute mapping (section 05) and run an end-to-end authentication test against your staging Connection using one or two institutional test accounts you provide — ideally one research-staff account and one administrator.

6. Step 06

   Promote to production

   Once staging passes, we promote the Connection to production and pin your institutional domain(s) so any user signing in with an email at those domains is routed to your IdP automatically. We send confirmation with the production sign-in URL your users should bookmark.

CSR requires the following attributes on every successful assertion. Institutions using Shibboleth or InCommon will recognize the eduPerson equivalents; either form is accepted.

NameID format: emailAddress is recommended. Transient or persistent NameIDs are supported if your institution requires them, provided email is released as a separate attribute.

Signed assertions

SAML responses must be signed by your IdP signing certificate.

Encrypted assertions

Supported if your policy requires it; we publish an SP encryption certificate as part of metadata.

Per-connection isolation

Your ACS URL, entity ID, and certificates are unique to your institution. There is no shared endpoint across customers.

Transport

TLS 1.2+ only. Legacy TLS and plaintext bindings are rejected.

Session behavior

CSR honors the IdP session length. Users are not kept signed in beyond the IdP's configured timeout. Single Logout (SLO) is supported on request.

Provisioning

New users are created just-in-time on first successful sign-in using the released attributes. SCIM-based lifecycle sync is available for institutions that require it.

Most institutions complete the integration in one to two weeks. The critical-path dependency is almost always the IdP ticket queue on your side; once we have received your IdP metadata, CSR typically finishes wiring and testing within one business day.

If your institution is preparing for a specific start-of-term or program kickoff, let us know at the beginning of the conversation. We can fast-track the staging Connection and pin a specific go-live date.