SSO Integration

Single Sign-On (SSO) allows users to access multiple applications using one set of credentials (e.g. their corporate login) instead of managing separate usernames or passwords per service.

What is Single Sign-On (SSO)

Single Sign-On (SSO) allows users to access multiple applications using one set of credentials (e.g. their corporate login) instead of managing separate usernames or passwords per service.

In your context, SSO enables your organisation’s users to use your Azure credentials to log into Crisisworks without needing a separate login in our system.

Key Benefits for Decision-Makers

Benefit	What It Means for You
Improved user experience	Users don’t need to remember additional passwords or manage separate accounts.
Stronger account security	Leverage your existing corporate identity policies (e.g. MFA, conditional access, password policies).
Centralised control of authentication	Your IT department maintains user provisioning, de-provisioning, and user lifecycle in your directory (authentication), while your Crisisworks admin maintains authorisation to positions and events within Crisisworks (authorisation).
Reduced helpdesk burden	Less password reset requests and fewer support tickets for account issues.
Scalability	We set up the integration once per customer (multi-tenant model) and maintain it.

How the Integration Works (High Level)

When your users signs into Crisisworks, our OAuth2 service redirects the user to your Azure auth service, and then it converts the Azure authentication result into a Crisisworks user by mapping against a user's email address.

The system is built using an open standard known as "OAuth2".

Here's a breakdown of the main concepts:

1. Your Azure service acts as an identity provider ("IdP") — that means when someone logs in, they’ll be redirected to Azure to authenticate using your corporate credentials.

2. Crisisworks acts as a “relying party” / “service provider” — after successful login, Azure issues a token (ID token / access token) containing user attributes. Crisisworks' OAuth2 service then maps those attributes to our internal user directory, issues its own tokens, and grants access to our systems.

3. Domain-based routing — Crisisworks supports multiple tenants, and it uses domain-based routing to work out which Azure service to use. You’ll nominate which email domains (e.g. @yourcompany.com) are associated with your Azure instance. Any login with an email in those domains is automatically redirected to your Azure instance for authentication.

4. Separate integration per customer — each customer’s SSO setup is isolated with unique client IDs/secrets, domain lists, and token mappings, to ensure we maintain a clean boundary across tenants.

5. Authentication in Azure; authorisation in Crisisworks — SSO provides authentication (the user is who they say they are). Authorisation of that user to content and features within Crisisworks is still managed by Crisisworks administrators using positions.

Crisisworks is designed to support a mix of internal and external users for emergency collaboration.

This means that you will have external agency users also signing in, with email addresses not covered by your SSO integration. For these users, they will still use email, password and MFA.

What You’ll Need to Provide / Decide

To get started, you (or your Azure admin) should fill out our SSO integration form, which includes:

• Identifiers & domains: the email domains that should route to your Azure instance

• Azure application registration details: client ID, client secret, issuer URL, scopes, endpoints

• Attribute mapping: which user attributes (e.g. first name, last name, email, username) we should receive from Azure

• Secret rotation plan: whether the client secret expires, and how/when we renew it

• Contact & support information: in case we need to liaise on tokens or troubleshooting

From your side, the main decisions are:

• Which domains will you delegate to this SSO integration.

• Whether you will require mandatory SSO for users on these domains, or whether you will support a fallback in the event of an SSO-related outage.

• How long the client secret should be valid, and who in your team will handle rotation.

Your IT team will need to ensure they have permissions to create or manage the needed “App registration” or “Enterprise application” in Entra ID.

Configuring Azure / Entra ID for SSO

What Happens After You Provide the Info

1. We configure your details in our system and map your domain(s).

2. We perform an initial connectivity test with you.

3. You’ll test with a small pilot group (e.g. power users).

4. Once validated, we enable SSO for your broader user base.

5. Ongoing support and periodic secret renewal sessions are arranged (typically 30 days before expiry).

Common issues

Sometimes integrations can go wrong and require maintenance. Here are the key things that may become issues.

• Certificate / key rollover: If Azure rotates signing keys, we may need to re-validate or refresh endpoints.

• Client secret expiry: If the secret expires unexpectedly without renewal, login will break.

• Domain collisions: Datalink requires each Azure integration to be responsible for non-overlapping domains.

• User overlap: If a user has accounts in multiple tenants, there is a risk of confusion; we assume users use corporate email tied to one domain.

• Support overlap: When providing support to end users, Datalink cannot reset passwords or provide guidance on SSO matters for users that cannot sign in. We will need a contact for support escalation.

• Timely collaboration: If something goes wrong in production, we will need timely access to a technical contact to help troubleshoot the integration.

What to Expect in Terms of Timeline & Effort

• Your Azure admin should expect ~1–2 hours to set up the app registration, gather the required values, and perform testing.

• Our team will do the backend configuration, which typically takes ½ hour.

• End-to-end testing with your pilot group may take another day.

• Secret rotation and periodic health checks can be scheduled annually or per your policy.

We’re happy to walk your executive or IT team through this at any time. Once you approve, we send you the SSO Integration Form link and schedule a kickoff meeting to walk through the roles, responsibilities, and timeline.