IT and SSO. Your handover

You are on your institution's IT team. First Six federates identity against your IdP, so most of your work is one-time application registration and a few feed wirings. None of it is heavy; the trick is sequencing it so the platform owner isn't blocked.

Your progress0 of 0 tasks

What's already done for you

By the time you reach this page, First Six has:

Implemented the standards-based OIDC sign-in flow, hardened with PKCE, nonce, state, and issuer + audience checks against your IdP's JWKS. The technical detail is in the OIDC flow.
Provisioned your tenant on a Sydney-region database (AWS ap-southeast-2).
Stood up an SIS-sync endpoint that accepts roster pushes from your upstream student information system. The contract is documented at the SIS endpoint.
Configured DNS for the platform's own subdomains (console., app., kb., status.). You don't need to host anything.

What's left for you is the connect-and-wire work below.

Identity (SSO)

This is the critical-path item. The platform owner can't run the launch checklist past step 2 until students can sign in.

Register First Six as an OIDC application in your IdP (Microsoft Entra is the live config; any OIDC-compliant IdP works). Required: authorization code flow with PKCE; redirect URI we provide; the openid email profile scopes at minimum.

Confirm the claims your IdP asserts in the ID token include sub, email, name, and email_verified (or a verified equivalent). If your IdP uses a UPN field instead of email, tell us. The linking RPC claim_sso_identity can match on either, but we need to know which.

Share the redirect URI configured at your IdP with your First Six contact so we can wire it into the per-tenant SSO config. We don't auto-discover this.

Provide at least one test account that exists in your IdP but is not a real student or staff member. We use it to walk the SSO flow end-to-end in a stand-in environment before pointing at production. See testing SSO before launch.

Confirm your IdP enforces MFA for the population that will sign in to First Six. We delegate MFA to your IdP by design. We don't re-enforce it on our side, so the policy you set is the policy that applies.

SSO is the only way in

Sign-in is SSO-only: there is no password path and no email magic-link fallback. Every sign-in goes through your IdP, under your MFA and conditional-access policies. That also means anyone who needs access (including contractors or external staff) must have an account your IdP can authenticate, such as a guest account in your directory.

Roster sync (SIS feed)

This isn't strictly blocking. You can hand-import students from the console. But for any cohort over a couple of hundred students it saves a lot of pain.

Walk the contract at the SIS endpoint. It accepts a JSON push of student rows (capped at 5,000 per call) and updates existing rows in place keyed by email + student_id_ext.

Receive the SIS shared secret from your First Six contact and store it in your secrets vault. Rotation cadence is 90 days. See secret rotation for how we coordinate the rotation.

Schedule the push from your SIS to the endpoint (typically nightly, sometimes hourly during enrolment changes). We don't pull. You push, so the cadence is yours to choose.

Calendar / timetable feed

Optional but recommended: students see their actual timetable inside the platform instead of bouncing to a separate system.

If you want timetable integration, share an iCal feed URL with your First Six contact. We wire it into Settings → Events feed on the admin console; the platform owner controls the per-cohort mapping.

Email and notifications

Allowlist the SendGrid sender domain we use for transactional email (sign-in links, help-request alerts, staff replies). Your First Six contact provides the exact domain so you can add it to your inbound allowlist / SPF reference.

If your network filters outbound traffic from student devices, allowlist app.firstsix.com.au and the W3C Web Push gateways (*.push.apple.com, *.googleapis.com, *.push.services.mozilla.com) so push notifications reach student devices.

Account lifecycle

Confirm with your team that IdP-side de-provisioning is the authoritative offboarding mechanism. When you disable a user in your IdP, they immediately can't sign in to First Six. We don't run a parallel local-account de-provisioning workflow. IdP is the source of truth.

Know that staff sessions are 8h and student sessions 30d by default, both server-side revocable. If you need to force-log-out a user before their session expires, the platform owner can revoke per-user or per-session from the Team page; tell them this exists.

No on-prem agent, no firewall change inbound

First Six is fully cloud-hosted. Vercel for the apps, Supabase (AWS Sydney) for data. There is nothing to install on your network and no inbound firewall opening required. All traffic is browser → our SaaS, plus your outbound push to our SIS endpoint and our outbound SMTP / push to your students.

What's already done for you

Identity (SSO)

Roster sync (SIS feed)

Calendar / timetable feed

Email and notifications

Account lifecycle

Next steps

Related