CKAN SSO with SAML2 and identity providers guide

How CKAN SSO with SAML2 changes who can log in to your portal

If your data portal must sign publishers and staff in through a corporate or government identity provider instead of local CKAN accounts, the ckanext-saml2auth extension adds SAML2 single sign-on to CKAN 2.10 and later. It can also assign users to organizations and roles, and manage sysadmins by email list, based on SAML2 attributes. The extension is the easy part. The harder work is deciding what your identity provider must send, what happens to the accounts CKAN already holds, and how narrowly you keep administrative power.

Attribute design comes first. The extension can only place a user in the right organization and role if the identity provider releases attributes that carry that meaning, in a stable and predictable form. Before any configuration, list each organization and role a publisher needs, then confirm with the identity provider team which attribute names and values exist today, who maintains them, and whether they change when a person moves teams. Ask for a test user per role so you can verify the mapping end to end before real publishers depend on it.

Existing local accounts need an explicit policy. Decide whether current CKAN users will keep password logins, be linked to their SAML2 identity by email, or be disabled after cutover. Mixed modes are where access drifts: a retained local sysadmin password is a bypass around your identity provider's controls. Also decide whether anyone may still self-register on the portal, and confirm how your installation's registration and login settings are configured, since SAML2 sign-in does not by itself turn off local registration.

Keep sysadmin access narrow. Because the extension can manage sysadmins by email list, every address on that list becomes a privileged account, and any change to the list takes effect on the next sign-in. Agree who approves additions and removals, review the list on a fixed schedule, and make sure sysadmin accounts use multi-factor authentication at the identity provider. Treat the list as a controlled record, not a convenience setting.

Plan for version alignment. CKAN targets about two minor releases a year, and the tech team supports the latest patch of the current minor version and the previous minor version. Minor releases may include backwards-incompatible changes, so an extension that works on one minor version may need work before you move to the next. Confirm with the extension's maintainers which CKAN versions the current release supports, and budget for retesting the SSO flow each time CKAN or the extension is upgraded.

Which CKAN and identity provider pieces the SSO work touches

SAML2 single sign-on for CKAN touches more than the login screen. The identity provider, the CKAN extension, the CKAN user and role model, the configuration file and the web server in front of CKAN each hold part of the behavior, and a change in one can silently alter who gets access in another.

The ckanext-saml2auth extension

This extension adds SAML2 single sign-on to CKAN 2.10 and later and can assign users to organizations and roles from SAML2 attributes. Confirm the exact option names and defaults in the extension repository for the CKAN version you run, because settings differ across releases and should not be copied from older guides. Pin the extension version and review its code as part of your CKAN extension inventory.

The CKAN user, organization and role model

CKAN grants access through users, organizations and per-organization roles such as member, editor and admin, plus a separate sysadmin flag that sits above all organizations. SAML2 attributes can map onto these objects, so decide in advance which attribute values create organization membership, which grant editor rights and which ever confer sysadmin. Test each mapping with a non-production account before go-live.

The CKAN configuration file

The CKAN configuration file holds the extension enablement, SAML2 options, session and cookie settings and the public site URL that the identity provider redirects back to. Mismatches between the configured URL, the protocol and the registered assertion consumer address are a common cause of failed logins. Keep the file under version control with secrets moved to the deployment's secret store.

The identity provider's metadata and attribute release

The identity provider must trust the CKAN service provider metadata, release the attributes CKAN expects, and sign or encrypt assertions as your security policy requires. Agree the attribute names, value formats and the user identifier with the identity team in writing. Ask who owns certificate rotation on the identity provider side and how the metadata is re-imported after a change.

The web server and certificate handling

The reverse proxy in front of CKAN terminates TLS, forwards the original host and protocol headers and must present a certificate that matches the URL in the SAML2 configuration. Check how the proxy handles the SAML response POST, request size limits and clock sync, since assertion validity windows are sensitive to skew. Plan certificate renewal for both the web server and the SAML signing keys.

Local accounts and the sysadmin list

Single sign-on does not remove CKAN's local registration and password login unless you disable them, and existing sysadmins may hold local passwords that bypass the identity provider. Inventory current accounts, decide which local logins stay as break-glass access and document who can change the sysadmin email list. Verify the outcome with a test that attempts local login after SSO is enabled.

Decisions to settle before configuring CKAN SSO

This table compares the five decisions that shape a CKAN SSO design, with the options, when each fits and what it costs to run. Read each row as a choice to make with your identity and portal owners before anyone edits the configuration. The main takeaway is that role mapping and sysadmin handling create most of the ongoing support load, so settle those first.

Decision	Option and when it fits	Ongoing administration and support cost
SAML2 path	ckanext-saml2auth fits when your identity provider speaks SAML2 and you want the extension maintained for CKAN 2.10 and later. Another SSO path fits when your provider only offers OIDC or a proxy is already in front of the portal.	Confirm the extension's CKAN version support and maintenance activity before committing. Each CKAN minor upgrade may need a compatibility check of the plugin and its settings.
Role mapping	Attribute-driven mapping fits large publisher populations where group membership in the identity provider is the source of truth. Manual role assignment fits small portals with few publishers and a stable team.	Attribute-driven mapping needs a named owner for the attribute contract. When a group name or claim changes upstream, users may lose organization roles and open support tickets until the mapping is corrected.
Sysadmin management	Managing sysadmins by email list keeps administrator rights tied to the identity provider lifecycle. Local sysadmin accounts kept for break-glass use fit when the identity provider or SAML2 login could fail and the portal must stay administrable.	Email lists need a review cadence so departed staff lose access. Break-glass accounts need credential storage, rotation and a documented test procedure, and they are a target if left unmanaged.
Local registration	Keeping local registration fits portals that accept external contributors outside the identity provider. Disabling it fits portals where every account must come from the identity provider.	Keeping it means a second account lifecycle to govern, including password resets and spam or abuse handling. Disabling it reduces accounts to manage but blocks any user without an upstream identity.
Publisher provisioning	Just-in-time provisioning fits publishers from many organizations who log in once and need access quickly. Pre-created users fit a fixed, approved publisher list where access must be granted before first login.	Just-in-time provisioning shifts work to attribute quality and organization mapping, which generate tickets when attributes are missing. Pre-created users add a request and approval workflow that someone must run and keep current.

Build sequence for CKAN SAML2 single sign-on

This sequence takes a CKAN portal from a compatibility check to production single sign-on through SAML2. Each step produces a named artifact, such as a metadata exchange, an attribute list, a config diff or a test account list, and a check closes it before the next step starts. Platform and identity teams share ownership of the early steps.

Confirm the CKAN minor version and extension support
The platform owner confirms the CKAN minor version in production and checks the ckanext-saml2auth repository for a release that declares support for that version. The extension supports CKAN 2.10 and later, so a portal on an older minor version needs an upgrade decision before SSO work starts. The artifact is a short compatibility note naming the CKAN version, the extension release and the Python version in use. The step closes when the platform owner signs off the pairing and the note is stored with the change record.
Agree the attribute contract with the IdP team
Platform engineering and the identity team agree in writing which SAML2 attributes the identity provider sends, including their names, value formats and whether each one is required. The output is an attribute list with one row per attribute, its source directory field, and the CKAN use it supports, such as organization or role. Ask the identity team to confirm how multi-valued attributes are sent and what happens when an attribute is missing. The step closes when both teams sign the list and the identity team confirms how changes to it will be released.
Exchange metadata and entity IDs in test
Build a test CKAN instance on its own hostname and exchange SAML metadata with the identity provider's test tenant. CKAN's service provider metadata file, with its entity ID and assertion consumer URL, goes to the identity team, and the identity provider metadata file, with its entity ID and signing certificate, comes back. Record both entity IDs and the certificate expiry date in the configuration register. The step closes when a test login completes the round trip and the assertion arrives with the agreed attributes.
Install and configure the extension
Install ckanext-saml2auth into the CKAN virtual environment, pin the exact release in the deployment requirements, and add the plugin to the CKAN configuration. The identity provider metadata location, entity ID, attribute names and callback URLs go into the environment-specific configuration file. Store the resulting config diff in version control so reviewers can see every change against the base file. The step closes when the CKAN service starts cleanly, the plugin loads without errors in the log, and the diff passes peer review.
Map attributes to organizations and roles
Translate the attribute list into CKAN organization membership and roles using the mapping the extension supports. Write a mapping table with one row per identity group: the attribute value, the CKAN organization, the role such as editor or member, and the named owner who approves it. Remove any mapping that grants rights without a named owner. The output is the signed mapping table. The step closes when a test user from each group lands in the expected organization with the expected role and no additional access.
Define sysadmin list and fallback access
Decide who holds sysadmin rights and write the email list the extension uses to assign them. Keep the list short, tie each address to a named person, and set the review schedule with the owner. Then decide whether local registration stays enabled and which account can sign in locally if the identity provider is unavailable. Document the break-glass account, where its credentials are stored and how it is tested. The output is the sysadmin list and an access decision record. The step closes when the security lead approves both and a test confirms the fallback login works.
Test with pilot users
Invite a small pilot group from each identity group in the mapping table and give each user a written test script. Pilot users sign in, create and edit datasets within their organization, and confirm they cannot change datasets in other organizations. Sysadmin and fallback paths get their own test cases. Record results in a test account list showing user, group, expected role, actual role and outcome. Failures go back to the mapping or the identity provider configuration. The step closes when every case passes or has a documented, accepted exception.
Cut over to production
Schedule the cutover with the identity provider team and apply the production metadata exchange, configuration diff and mapping table through the same change process used for other releases. Keep the previous login configuration available for rollback until the first production users sign in successfully. After the switch, verify production login, role assignment and the break-glass account. The output is a change record with the verified configuration and a rollback note. The step closes when the platform owner confirms production logins match the pilot results.

What drives the effort and cost of CKAN SSO

This table lists the factors that most change the work of adding SAML2 single sign-on to CKAN, with a practical way to keep each one contained. Read it as a checklist to scope with your team before asking for a quote, since the first two or three drivers usually set most of the effort.

Driver	Why it changes effort or cost	How to keep it down
Number of identity providers or tenants	Each IdP needs its own metadata, certificate handling, test logins and attribute checks, and a shared login page may need routing logic.	Confirm early which IdPs must sign in to CKAN and retire any that are not needed for this portal.
Cleanliness of IdP attributes	Missing, multi-valued or inconsistently formatted email, group or role attributes force custom parsing and manual exceptions.	Agree one attribute contract with the identity team covering names, formats and required fields before configuration starts.
Organizations and roles to map	Every CKAN organization and role that depends on an IdP group adds mapping rules, edge cases and test accounts to verify.	Map only the organizations that need automatic assignment and keep the rest manual until the first release.
Existing local users to migrate or retire	Local accounts with duplicate emails, unused logins or stale roles need matching, merging or disabling, and each decision needs sign-off.	Count local accounts in the target environment, set a retirement rule and confirm who approves account merges.
Multiple environments needing metadata exchange	Development, test and production each need their own SP metadata, IdP registration, certificates and callback URLs.	Stand up a staging environment first and reuse the same configuration pattern for production with only endpoint and certificate changes.
Custom extensions touching authentication or user pages	Existing CKAN extensions that alter login, user profiles, password flows or sysadmin screens can conflict with the SAML2 plugin and need review and testing.	Inventory third-party and custom extensions at the start and confirm which ones hook into user or authentication code.
Sysadmin and local registration controls	Deciding who becomes sysadmin, whether self-registration stays on and how the sysadmin email list is maintained adds policy work and testing.	Document the sysadmin list and registration policy as written decisions before implementation, and check the plugin's current options for each.
Compliance evidence needs	Assessors may ask for configuration records, access reviews, test results and change history, which take time to assemble and keep current.	Ask your compliance lead which evidence the assessor expects and capture it during testing rather than after go-live.

How SSO setup differs across single node, high availability and air-gapped CKAN

On a single node, CKAN runs behind Nginx, which terminates TLS and forwards requests to uWSGI, which serves the CKAN application. The SAML2 flow is handled entirely within this one host, so there is only one place where session state and the service provider (SP) certificate live. This keeps the setup closest to the reference configuration, and most of the work is about getting the URLs, certificates and attribute mappings right.

What to set up on a single node:

Public base URL: The SP entity ID, assertion consumer service URL and CKAN site URL must match the hostname the identity provider (IdP) sends users back to, including the scheme and any port.
Nginx and uWSGI headers: Confirm the forwarded protocol and host headers reach CKAN, so SAML redirects are not generated as plain HTTP.
SP certificate and key: Store the key with restrictive file permissions on the host, and keep a documented process for renewal before expiry.
IdP metadata: Load the IdP metadata file the IdP administrator issued for this SP, and record its version and date.
Test users: Verify login, attribute mapping to organizations and roles, and logout with a test account before opening access.

Confirm the exact configuration keys and session storage options against the ckanext-saml2auth documentation for your CKAN version and the topology you have, rather than assuming defaults carry over.

Access control and secrets handling for CKAN SSO

Once CKAN trusts an identity provider, the portal's security depends on who gets elevated rights, which attributes the IdP releases, and how the SAML2 keys are kept. The cards below cover the decisions and checks that connect the ckanext-saml2auth configuration to day-to-day access control. Patch policy and API token hardening are covered in the CKAN security hardening topic.

Restrict sysadmin rights to a short list

The ckanext-saml2auth extension can manage sysadmins through an email list, so sysadmin status becomes a configuration decision rather than a manual account edit. Keep the list short, name an owner for it, and review it on a fixed schedule. Check that a removed person loses sysadmin rights on their next login and that no accounts retain elevated rights from before SSO was enabled.

Keep a tested fallback admin path

If the identity provider is unavailable or its certificate expires, administrators must still be able to reach CKAN to repair it. Decide on one fallback path that does not depend on SAML2, such as a local sysadmin account held under dual control, and store its credentials in the organization's password vault. Test the fallback login before go-live and after each configuration change, and record the test.

Set SAML message signing and encryption

Confirm with the identity provider team which signing and encryption settings they require for assertions and responses, and configure CKAN to match exactly. Mismatched settings typically fail at login rather than at setup, so test with each IdP environment separately. Ask the IdP owner who approves changes to these settings and how they are communicated to the CKAN team.

Protect the service provider key and certificate

The service provider private key lets CKAN sign requests, so it needs the same custody rules as other production secrets. Keep it out of source control and shared configuration files, limit read access to the process that runs CKAN, and record the certificate's expiry date with an owner. Plan rotation as a documented procedure with a tested rollback, and confirm the IdP accepts the new certificate before the old one expires.

Limit the attributes the IdP releases

Attribute mapping decides which organizations and roles a user receives, so every attribute CKAN reads is an access decision. Request only the attributes needed for mapping, agree the attribute names and value formats in writing with the IdP owner, and test how CKAN behaves when an attribute is missing or has an unexpected value. Treat any role claim that is not explicitly mapped as having no effect.

Disable or limit local registration

Once SSO is the intended sign-in route, open self-registration on the CKAN site creates accounts outside the identity provider's control. Decide whether local registration is turned off entirely or limited to a named group, and confirm the setting in the running portal rather than only in the configuration file. Review existing local accounts and decide which ones should be disabled, reassigned or kept as documented exceptions.

Reconcile API tokens with account ownership

Existing API tokens were issued to local accounts, and after SSO is enabled some of those accounts may belong to people who have changed roles or left. Review which tokens map to which accounts, confirm each owner still needs the access, and revoke tokens that belong to departed users or shared logins. Record the review date so the next review has a baseline. Token handling rules themselves are covered in the CKAN security hardening topic.

How to test CKAN SAML2 login and confirm it fails safely

Test the CKAN SAML2 integration against a staging portal that uses the same ckanext-saml2auth configuration as production, and treat each failure path as a requirement with a pass or fail result, not a formality. The most important outcome is not that a valid user can sign in. It is that every invalid or unexpected identity is refused, and that a broken identity provider leaves the portal in a state where an operator can still get in. Record the expected result for each case before running it, so the team agrees on what success looks like. Start with the happy path. Create a test user in the identity provider who belongs to a known group or carries the attribute values your mapping expects. Sign in for the first time and confirm the CKAN user is created, the email and display name are populated, and the user lands in the organization and role that the attribute mapping specifies. Then change that user's attribute in the identity provider, for example by removing the group, and sign in again. The user should lose the organization role on the next login, and gain it back when the attribute is restored. Confirm that the change takes effect at login and not only after a manual sync, because operators often assume the reverse. Next, test the negative cases. A user missing the required attribute must be denied with a clear message, and no CKAN account should be created or elevated as a side effect. Sign in with an email address that is not on the sysadmin list, even if the identity provider asserts an admin-looking group, and confirm the account cannot become a sysadmin. Then deliberately break the identity provider signing certificate in staging, or point the portal at the wrong certificate, and confirm that SAML responses are rejected rather than accepted. Confirm that the failure produces an error page, not a silent local account. Check the CKAN logs for each case. Login attempts, account creation, role changes and authorization decisions should appear with enough detail to reconstruct what happened, including the user identifier and the outcome, without writing assertion contents or secrets. Confirm the fallback admin path still works by signing in with the local sysadmin account during the broken-certificate test, then remove that access and verify it stays removed. Finally, run a rollback test: disable the SAML2 plugin, restart the portal, confirm local login works, and verify that datasets, organizations and user records are unchanged. Confirm exact log locations, required settings and the supported ckanext-saml2auth version against your CKAN minor version and the extension repository before you write the test plan.

What to monitor, document and renew after SAML2 goes live

Going live is the start of the SSO lifecycle, not the end of it. The checks below cover login health, identity provider certificates and metadata, who holds sysadmin rights, and how the integration is retested as CKAN and the extension change. Each item feeds the next, so a missed renewal or an untested upgrade shows up as a login failure or an access error.

Monitor login failures and metadata expiry

Track failed SAML2 assertions, rejected signatures and redirect errors in the CKAN and web server logs, and alert on them rather than waiting for user reports. Record the expiry dates of the service provider and identity provider signing certificates and the date the IdP metadata was last refreshed. Ask your identity team which certificate the IdP signs assertions with, because that is the one that breaks logins when it lapses.

Review sysadmins and role mappings

Set a recurring review of the sysadmin email list and of the rules that map SAML2 attributes to organizations and roles. Remove accounts for leavers and contractors, and confirm that each mapping still matches the groups your identity provider issues today. Because sysadmin access is granted by list in the extension, a stale entry keeps full administrative rights until someone removes it.

Retest SSO after each upgrade

Run a scripted login test covering new users, returning users, role mapping and logout after every CKAN patch and minor upgrade, and after every update to ckanext-saml2auth or other extensions in the login path. CKAN minor releases may include backwards-incompatible changes, so each minor version change may require the extension to be retested against the new release before the upgrade reaches production.

Back up configuration and certificates

Store the SSO configuration, the service provider private key, the certificates and the attribute mapping in your secrets store, and keep a versioned copy of the configuration alongside the CKAN deployment settings. Confirm who can read the private key, how restores are tested, and that a rebuilt server can be brought back into the same identity provider registration without guessing at values.

Document the attribute contract

Write down each SAML2 attribute CKAN expects, its format, the identity provider that issues it, and the organization or role each value maps to. Keep this contract with the identity provider owner, since a renamed claim or a changed group format will quietly remove access for a set of users. Review it whenever the identity provider changes its attribute release policy.

Maintain the certificate rotation runbook

Write a step-by-step runbook for rotating the service provider certificate: generating the new key pair, updating the identity provider registration, deploying the new configuration, verifying a test login, and retiring the old certificate. Name the people who approve each step and rehearse the runbook in a non-production environment before the first real rotation, so the change does not depend on memory.

Questions teams ask before hiring help with CKAN SSO

How much does CKAN SAML2 single sign-on cost to set up?

The ckanext-saml2auth extension is open source, so there is no license fee. The cost is the people and environments needed to do the work. One-time costs cover scoping, identity provider configuration, extension installation, attribute mapping, testing in a staging CKAN and a handover document. Recurring costs come from keeping the integration working as CKAN moves between minor versions, rotating identity provider signing certificates and any support retainer. Costs rise with the number of identity providers, the number of organizations and roles mapped from attributes, custom login behavior and the number of environments that must be tested. Ask for a fixed-scope quote that prices each of these items separately. DeployOpen does not publish prices, so a quote follows from the written scope.

How long does CKAN SSO with an identity provider take?

Duration depends mostly on the identity provider and on how the SAML2 attributes are designed, and much less on CKAN itself. An identity provider that already issues clean, documented group or role attributes usually moves quickly. Delays appear when group membership must be derived from several sources, when the identity team must create new claims, or when metadata exchange, certificate issuance and test accounts wait on approvals. Ask for the schedule to be tied to named milestones: attribute inventory, metadata exchange, staging login test, role mapping test and production cutover. This page does not state a duration because it depends on your environment. The estimate should come from the written scope for your identity provider and attribute design.

What does CKAN SSO need from our identity, security and CKAN teams?

The identity team provides access to the identity provider or a named change owner, the SAML metadata exchange, the attribute names and values that carry organization and role information, and test users. The security team confirms signing and encryption requirements, certificate lifecycle, logging expectations and who approves sysadmin assignment. The CKAN team confirms which organizations exist, which roles each needs, how local registration should behave and who owns the production configuration after go-live. Agree on these owners before work starts. Most delays come from an open question that nobody can answer, not from the technical configuration itself.

Can our in-house team set up ckanext-saml2auth without outside help?

Yes, if the team already runs CKAN in production and has someone who is comfortable with SAML2 and identity provider administration. Because the extension is open source, no purchase is required. The usual gap is experience with attribute mapping, edge cases and testing. Check whether your team can answer these questions: how a user in no group or in many groups is handled, what happens when a user leaves a group, who reviews sysadmin assignments, and how the integration is tested after each CKAN patch or minor upgrade. If the answers are unclear, an outside review of the design or a fixed-scope implementation can be scoped separately from the rest of the portal work.

How do we confirm ckanext-saml2auth supports our CKAN version?

Check the extension's repository for the CKAN versions it declares as supported, then match that list against the CKAN version you run. The extension adds SAML2 single sign-on to CKAN 2.10 and later, so confirm the exact range in the repository's documentation, release notes and requirements for the version you plan to install, since supported lists can change. Also check your CKAN minor version against the release policy: the CKAN team supports the latest patch of the current minor version and the previous minor version. If your portal runs an older minor version, plan the upgrade before SSO work or include it in scope. Test in staging at the same CKAN patch level as production.

How do SAML2 attributes map to CKAN organizations and roles?

The extension can assign users to CKAN organizations and roles based on SAML2 attributes. Effort depends on how clean those attributes are. A single group claim with clear names is simpler than several attributes that must be combined, nested groups, or values that need translation into CKAN organization names. *Illustrative example:* a group named publishers-health might map to the health organization with the editor role. Each mapping rule needs test cases, including a user with no group, a user in several groups and a user removed from a group. Ask the identity team to document attribute names and values and who may change them. Keep mapping rules in version control so changes can be reviewed.

What should a fixed-scope quote for CKAN SSO list?

A fixed-scope quote should name each deliverable and each assumption so both sides can see what is included. List the identity providers in scope, the service provider metadata to be produced, the attribute map, the organization and role mapping rules, the approach for sysadmin assignment, the decision on local registration and the environments to be configured and tested. Also list the test cases, the handover documents, the acceptance criteria, the change process for scope requests and the client responsibilities such as identity provider access. State what is excluded, including any CKAN upgrade, theming or custom extension work. Finally, state whether post-go-live support is included or sold separately as a retainer. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Should we keep local CKAN logins after SAML2 single sign-on is live?

This is a policy decision with a technical side, and it should be made before configuration. Many teams keep a small number of local administrator accounts for recovery if the identity provider is unavailable. Confirm in the extension documentation how existing local accounts are treated after SAML2 is enabled and whether local registration can be turned off. Decide who holds sysadmin rights, keep that list short, and review it on a fixed schedule, since the extension can manage sysadmins from an email list. Document the recovery procedure, test it in staging and record who may use it. The security team should approve the final approach because it determines how an attacker would reach an administrator account.

How DeployOpen scopes, builds and hands over CKAN SSO work

DeployOpen plans, implements, documents and supports CKAN SSO with SAML2 and identity providers inside your own infrastructure, using the ckanext-saml2auth extension. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts.

How we scope

Inventory your identity provider, its SAML2 metadata, and the attributes it releases for each user
Agree which attributes map to CKAN organizations, roles and sysadmin assignments in writing
Confirm whether local registration stays open, closes, or is limited to named exceptions
Record the CKAN version, hosting model and any custom extensions that touch authentication

How we build

Install and configure ckanext-saml2auth on a CKAN 2.10 or later test environment
Build attribute-to-role mapping rules and test them against sample identity provider accounts
Test sysadmin management by email list and confirm local login behavior for break-glass access
Review the configuration for exposure of secrets, certificates and session settings before promotion

How we hand over

Document the SAML2 configuration, attribute mappings and the identity provider settings that must stay in sync
Provide a test script and results covering login, logout, role assignment and denied access cases
Walk your operations and identity teams through certificate renewal and metadata update steps
Deliver written runbooks for changing mappings, adding sysadmins and rolling back a faulty change

How we support

Ongoing support and upgrades are available as a retainer, covering extension compatibility with new CKAN releases
Retest SAML2 login after CKAN patch, minor or Python changes, because each release can affect extension behavior
Confirm with your identity provider vendor any changes to certificates, endpoints or attribute names before they take effect
Agree the support response and change process in the written scope, not in general terms