Security Onion SSO with OIDC guide

How do you set up Security Onion SSO with OIDC for analysts?

OIDC single sign-on for the Security Onion Console is a Security Onion Pro feature. The free edition does not offer it and uses local console accounts that the platform team creates and maintains. If your SOC wants analysts to sign in with their corporate identities, plan for the Pro edition, or accept local accounts and the offboarding work they bring. The work is harder than it looks because the decisions sit in two places at once. The identity provider decides who authenticates, which groups a user belongs to, and what claims are sent to the console. The Security Onion Console then decides what those claims mean in terms of access. A mismatch in either system can leave an analyst signed in with too much access, or locked out with no obvious error. Before you start, write down which groups map to which console roles and who approves changes to that mapping.

Lockout risk is real. If the OIDC configuration breaks, or the identity provider is unavailable, analysts cannot reach the console. A tested fallback is therefore a precondition, not an afterthought. Confirm with the vendor how the Pro edition handles a local administrator path during SSO outages, and test that path on a non-production grid before cutover. Keep the break-glass credentials stored where the on-call team can reach them without depending on the identity provider.

Start by confirming the supported identity provider types in the Security Onion Pro documentation or with the vendor. Do not assume a specific provider works because it supports OIDC in general. Also confirm which claim fields the console reads, whether group membership is passed in the token or must be looked up separately, how sessions expire, and how role changes take effect for users who are already signed in. Each of these answers changes the design of your group structure and your test plan.

Decide the role model before you touch the configuration. Map analyst tiers, such as read-only triage, detection engineering and administration, to identity provider groups, and keep the list short enough that a reviewer can check it. Test each role with a real account from each group, confirm that a removed group membership actually removes console access, and record the results as evidence. An illustrative example: a leaver whose group is removed should lose console access at their next session check, and your test should show that happening, not assume it.

Which parts of the Security Onion stack does SSO touch?

Single sign-on in Security Onion involves more than the login page. Identities, groups, client registrations and console permissions sit in different places, and each one needs an owner during planning. The cards below separate the components so you can map where access is decided before you choose an edition or an identity provider.

Security Onion Console

The Console is where analysts log in and where access to hunting, alerting and detection views is enforced. For OIDC, check how the Console maps incoming identities and groups to its own roles, and confirm which permissions a user receives when group membership is missing or changes. Test each role with a non-administrator account before rollout.

Manager node hosting the Console

The manager node serves the Console and holds the configuration that governs login, so its availability affects every analyst session. Plan maintenance windows and backups for it as a single control point. If the manager goes down, search nodes stop indexing, which means a sign-in outage also becomes a monitoring gap.

Local console accounts in the free edition

The free edition relies on local console accounts stored on the platform rather than on your directory. These accounts hold their own passwords and roles, so every joiner, leaver and role change must be handled by hand. Document who creates and removes them, and confirm how they are audited, because they sit outside your central identity lifecycle.

OIDC identity provider and client registration

Your identity provider holds the user identities, group memberships and the client registration that represents the Console. The client registration carries a client identifier, a client secret and the redirect addresses the Console is allowed to use. Confirm who owns the secret, how it is rotated and which redirect addresses must match your Console hostname exactly.

Security Onion Pro OIDC single sign-on

OIDC single sign-on to the Console is a feature of Security Onion Pro, a paid edition sold on 1 to 5 year terms. Factor the license term and renewal into the decision, since the free edition does not provide this login path. Confirm the current Pro documentation for supported providers and the exact configuration screens before you plan the integration.

Security Onion API and automation access

The Security Onion API is a related Pro feature that scripts and integrations may call. It requires its own credentials and access decisions, separate from analyst logins, so an SSO change does not automatically cover automation. Inventory every service account and token, decide which roles they need, and confirm in the Pro documentation how API access is authenticated.

Which SSO and account decisions should you make before you build?

This table compares the account and identity decisions to settle before configuring Security Onion SSO with OIDC, along with the ongoing work each one creates. Read each row as a fork: the first column names the choice, the second lists the conditions where it fits, and the third lists the recurring work it adds. The main takeaway is that SSO moves effort from console administration to identity administration, so the identity team should own those costs from the start.

Decision	When it fits	Operational cost
Pro OIDC SSO or local console accounts	Pro suits many analysts who need central joiner and leaver control. Local accounts suit a small team with few access changes.	Pro is a paid edition on a 1 to 5 year term. Local accounts need manual creation, password resets and removal for every change.
One local break-glass console account alongside SSO	Use it when an identity provider outage or a misconfigured OIDC setting must not lock every analyst out of the console.	Store the credential securely, rotate it on a schedule and test sign-in. Review its use, since it bypasses the identity provider.
Role mapping from IdP groups or console assignment	Map from groups when the identity team already tracks analyst duties. Assign in the console for a small, stable analyst set.	Group maintenance sits in the identity provider. Renamed or removed groups can change console access, so confirm the mapping behavior in the docs.
MFA at the identity provider or console controls	Enforce at the identity provider when it already covers every application. Confirm which console-side MFA options exist before relying on them.	Policy changes happen in one place, but the break-glass account needs its own second factor process. Audit both sign-in paths.
One identity provider for all grids or separate registrations	One provider fits grids in one trust domain. Separate registrations fit isolated networks or environments with different owners.	Each registration has its own client secret and redirect settings to maintain. One provider outage affects every grid that depends on it.
Client secret rotation and identity provider availability	Applies to every OIDC setup, whichever registration model you choose.	Plan secret rotation windows that keep sign-in working. Sign-in stops when the identity provider is unreachable, so confirm the fallback path first.

How do you build Security Onion SSO with OIDC step by step?

This sequence moves a Security Onion Console from local accounts to OIDC single sign-on with role-based access for analysts. Each step closes with a check, so the team knows the connection, the role mapping and the fallback account work before the rest of the analysts are switched over.

Confirm Pro licensing and target version
The platform owner confirms in writing with Security Onion Solutions that the license covers OIDC single sign-on on the grid. Confirm the target version as well: Security Onion 3.x is the current major line, and 2.4 reached end of life on October 1, 2026, so a grid still on 2.4 needs its migration planned before SSO work starts. The step is done when the license entitlement and the target version are recorded in the change ticket and both match the grid under build.
Confirm console URL and DNS name
The network team picks the fully qualified name analysts will use for the Console and confirms it resolves to the Console from analyst workstations and the jump hosts they use. The certificate must cover that same name, because the identity provider redirect depends on it. The step is done when name resolution, the browser trust chain and the certificate subject all match the name written in the design record.
Create the OIDC client in the identity provider
The identity administrator creates an OIDC client for the Console in the identity provider and registers the redirect URI exactly as the Security Onion Pro documentation specifies, matching scheme, host, port and path. The client secret goes into the team's approved secret store, not into a shared document. The step is done when the identity provider's discovery document loads and a test authorization request from the client reaches the sign-in page without a redirect error.
Define analyst groups and role mapping
The SOC lead and the identity administrator agree on the analyst groups in the identity provider and map each group to one Console role, starting from the minimum access each analyst needs. Confirm the role names and what each role can do in the Pro documentation rather than assuming them. The step is done when a written matrix lists every group, its Console role and the actions it permits, and the SOC lead approves it.
Secure and test the break-glass account
Before SSO is enabled, the platform owner keeps a local administrator account on the Console as a fallback if the identity provider is unavailable. The password is stored in sealed custody with a named owner, and the account is excluded from the group mapping. The step is done when someone logs in with the local account from the Console and the login is recorded, confirming the fallback works while the Console still uses local accounts.
Configure the OIDC connection in the Console
The platform engineer enters the issuer, client ID, client secret, scopes and group claim settings in the Console, using the values confirmed from the identity provider and the Pro documentation. Changes are made in a maintenance window with the break-glass account already logged in. The step is done when the configuration saves without error and the Console reports the OIDC connection as active in the settings view.
Test sign-in with a pilot user from each role
The team signs in with one pilot account per role in a fresh browser session. Each pilot should land in the Console with the expected role, and a lower-privilege pilot should be denied an action reserved for a higher role, such as changing detection tuning or system settings. A user in no mapped group should also be refused. The step is done when every pilot result matches the role matrix and the results are written down.
Roll out SSO to remaining analysts
The team moves the remaining analysts to SSO in stages, grouped by role, and watches the Console and identity provider logs for failed sign-ins and group mismatches after each stage. Local accounts are disabled according to the team's access policy, while the break-glass account stays in place and is tested again. The step is done when every active analyst signs in through SSO, the access review is documented, and the break-glass test result is recorded.

What drives the effort and cost of Security Onion SSO?

This table compares the factors that change how much work Security Onion SSO with OIDC takes and what keeps recurring after go-live. Read each row as a driver: the middle column explains the effect, and the last column names the lever you control. The main takeaway is that directory state, group ownership and the number of grids usually matter more than the console settings themselves.

Driver	How it changes the work	How to keep it down
Identity providers and tenants	Each identity provider or tenant needs its own OIDC trust, claim mapping and login test. Multiple tenants multiply that work for every console.	Confirm which identity provider is authoritative for analysts. Limit each console to one provider and tenant where your policy allows.
Analyst roles and group structure	Every Security Onion role needs a matching directory group and a tested login. More roles mean more mappings and more test cases.	Map a small set of roles to groups that already exist. Name groups after job functions so mappings stay easy to review.
Grids and environments needing separate client registrations	Each production, test or lab grid typically needs its own client registration and redirect address. Confirm the exact registration steps with Security Onion Solutions.	Use consistent naming for registrations. Keep one matching test grid for upgrades and SSO changes instead of building a new one for each change.
Who owns group changes	If the directory team owns groups, role changes pass through a ticket queue and analysts wait. If the security team owns them, changes are faster but need directory rights.	Write down who approves each group, who makes the change and how long a change can take. Agree this before design starts.
Compliance evidence of access reviews	Assessors usually ask who had access, when it was reviewed and who approved it. A working login alone does not show a review took place.	Export group membership on a fixed schedule. Store review records with the change tickets. DeployOpen prepares evidence, but auditors issue any reports.
Internet-connected or airgapped grid	Airgapped grids can only use an identity provider reachable from their network. Internet-connected grids may reach a cloud provider directly.	Decide where the identity provider sits during scoping. Document the network path, certificates and firewall rules the console needs.
State of the existing directory	Clean groups map quickly. Legacy nested groups, stale accounts or unclear claim formats add cleanup and testing before roles can be trusted.	Inventory nested groups and stale accounts first. Confirm with the identity owner which group claims the provider sends in tokens.
Secret rotation and group reviews (recurring)	Client secret rotation and periodic group reviews repeat for the life of the deployment. Each rotation needs a coordinated change on both sides.	Schedule rotation with the identity provider owner. Automate membership exports so each review starts from current data.
Pro license and setup (one-time and recurring)	Pro is sold on 1 to 5 year terms, so the license renews at the end of each term. Initial registration, mapping and testing are one-time work.	Ask quotes to separate one-time setup from term licensing. Pick a term length that matches your planning and budget cycle.

How should analyst roles map from identity provider groups?

Start from the tasks each group needs, not from the list of groups your identity provider already has. In the Security Onion Console, three task areas matter: viewing alerts and hunting through events, tuning detections, and administering the grid. The Detections interface manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka, and it offers modify, suppress and threshold tuning for NIDS rules. Anyone who can change those rules can change what the SOC sees, so write down the tasks first and decide which people perform each one before you touch the mapping.

Map each identity provider group to one task or one clearly defined combination of tasks. For every group, record the group name, the Console role it grants, a named owner who approves membership, and the date of the last review. Keep this mapping in version control or a change record so that every change has an author and an approval. The most common failure here is group sprawl: teams create groups for projects, nobody removes them, and a stale group quietly keeps a former employee or contractor's access alive. Restrict detection tuning and grid administration to a small named group, and give broad read access to the wider analyst group.

Confirm the platform details before you build the mapping, because they are specific to your Security Onion version and your provider's configuration. Confirm the exact role names the Console supports, the claim or group attribute the Console reads from the identity token, and whether group values must match your provider's group names exactly. Then confirm whether a role change applies at the next login or only after a session reset, and whether removing a user from a group revokes access immediately or only when their current session ends. Your answers determine how quickly an offboarding or role change takes effect, so put them in writing.

Set a membership review cadence that the owner of each group can sustain, and record the outcome of every review. At each review, compare the members against current job roles, remove leavers and people who have changed teams, and confirm that the owner still needs the group. Before rollout, test with a dedicated test account in each group and check that a viewer can see alerts but cannot change a suppression or threshold, and that only the administrative group can reach grid settings. Keep the test results and review records with the mapping. DeployOpen can prepare these controls and their evidence for your assessment, but independent auditors decide whether they meet your requirements.

How does the SSO setup change by deployment model?

A standalone node runs the console and the data services on one host, so the identity path is the simplest of the four models. Every analyst signs in to the same console on that host, and the redirect, callback and token checks all involve one system. The trade-off is that the host is also the single point of login failure. If it is down, no analyst reaches the console, and no second console exists to fall back on.

One callback target: register one console hostname and confirm the redirect URL matches the identity provider configuration exactly.
No console redundancy: define a local recovery path for the host, and store and test it under your break-glass procedure.
Host dependencies: token validation depends on time synchronization and name resolution on that host, so check both before go-live.
Deployment type: Import and Evaluation types also exist, but Distributed is the recommended production design, so confirm whether a standalone node is a deliberate production choice.

Confirm with the vendor how the console behaves when the identity provider is unreachable and whether local console accounts remain available in your edition before you accept this model.

How do you protect console access and secrets during SSO setup?

Moving the Security Onion Console to OIDC single sign-on shifts the main access decision from local passwords to the identity provider and to the people who can change that trust relationship. The cards below cover the controls that protect sign-in, the OIDC client secret, the SSO configuration, the break-glass account, offboarding and network exposure.

Require MFA at the identity provider

Enforce multi-factor authentication in the identity provider for every account that can reach a Security Onion Console role, not only administrators. Because the console trusts the provider's sign-in result, a weak provider policy becomes the console's weakest point. Check that conditional access or sign-in policies apply to the application registration used for the console, and confirm that no legacy authentication path bypasses them.

Keep the client secret out of shared channels

The OIDC client secret lets the console exchange tokens with the provider, so treat it as a production credential. Do not paste it into tickets, chat threads, wiki pages or change records. Store it in the approved secrets manager, limit read access to the people who maintain the console, and record where it is injected during configuration so rotation is a known task rather than a search through old messages.

Restrict who can change SSO settings

Changes to the OIDC issuer, client ID, redirect address, role mappings or group claims alter who gets into the console and with what privileges. Limit edit rights on these settings to a named small group, separate them from analyst roles, and require a reviewed change for each modification. Confirm that the console's own role assignments cannot be elevated by an analyst account.

Hold the break-glass account under dual control

Keep one local console account for use when the identity provider or SSO path is unavailable. Set a long, unique credential, store it in a sealed vault entry that requires two authorized people to retrieve, and log every use. Test that the account works before go-live, and confirm the procedure for rotating its credential after each use so it cannot be reused quietly.

Review sessions and remove leavers promptly

Deprovisioning in the identity provider should end console access, but confirm how long an existing console session remains valid after a user is disabled and whether the console honors provider revocation. Build a recurring review of who holds each console role against the current staff list, and include contractors and service accounts. Document who performs the review and where the record is kept.

Limit console exposure to the analyst network

Serve the console only on the analyst network segment and restrict inbound access to the required ports from approved analyst addresses. Keep management interfaces and the sensor and search node networks separate from the console's user path. Verify the restriction from outside the allowed range, because the identity provider's sign-in success does not protect a console that is reachable from every network.

How do you test that SSO works and fails safely?

Test SSO before anyone relies on it by running a fixed set of cases and recording each result. The core set covers a successful login for each analyst role the Security Onion Console uses, a denied login for a user who belongs to none of the approved groups, and a user who is removed from a role group and then tries to sign in again. For each case, write down the expected outcome before the test runs, the account used, its group membership at the time, and the observed result. Role tests should confirm more than the login itself: an analyst should reach the views and actions their role permits and nothing above that. Denial tests should include accounts from other groups with similar names, so that a loose group match does not pass unnoticed.

Two lifecycle tests catch problems that a first sign-in will not reveal. The first is group removal. After you take an account out of the role group in the identity provider, confirm how long it takes the Console to stop granting that role and whether an existing session stays usable until it expires. Ask Security Onion Solutions how role claims are read at login and whether the Console refreshes them during an active session. The second is client secret rotation. Generate a new OIDC client secret in the identity provider, update the Console configuration, then sign in with a test account and confirm that the old secret no longer works. Record each step so the change runbook matches what actually happened.

Failure tests show whether the platform fails safely. Block the Console host's path to the identity provider, attempt a sign-in, and record what the user sees and whether the login page reports the fault clearly. Confirm with the vendor what the Console does with existing sessions in that state. Then test the break-glass path. Confirm that a local Console account exists, that its credentials sit under your privileged account process, and that it works while SSO is disabled and while the identity provider is unreachable. Each use of that account should produce a log entry that reaches your central logging, and someone who does not administer the account should review those entries on a schedule your policy sets. Test the review step as well, so you can show it happens.

Keep evidence in a form that a change reviewer or assessor can follow without asking you questions. For each test, capture the test ID, the expected and observed result, the date, the tester's name, and the Console and identity provider versions in use. Attach screenshots of the login outcome and the role-specific view, an export of the relevant authentication configuration with client secrets and other credentials removed, and the identity provider sign-in log entry for each attempt. Store the test script and results with the change record. DeployOpen can prepare the test plan, run the tests and assemble this evidence. It does not issue audit reports or attestations. An independent auditor or certification body decides what your evidence supports.

Run all of these tests on a test grid that matches production in the ways that affect authentication: the same Console version, the same DNS names and certificate chain, an identity provider tenant or realm that mirrors the production group structure, and the same break-glass procedure. A test grid with a different hostname or a shared test group can pass for reasons that will not carry over to production. Repeat the full set after any Console upgrade, identity provider change or group restructuring, not only the first time. Schedule the repeat in the same change window as the upgrade so the evidence stays current. Ask your implementation partner to confirm in writing which test grid components are in scope.

What must you monitor, rotate and document after go-live?

Single sign-on changes who can reach the Security Onion Console, so the controls around it need an owner and a schedule after go-live. The cards below cover monitoring, access reviews, credential rotation, emergency access, subscription tracking, documentation and upgrade retesting.

Monitor failed logins and console access

Review failed sign-in attempts at the identity provider and in Security Onion logs, and watch for changes to console access or role assignments. Confirm which events are forwarded to your monitoring stack and who receives alerts for repeated failures. Without this, a misconfigured or abused OIDC flow can go unnoticed until an analyst reports a problem.

Review group membership on a set cadence

Role mapping in Security Onion Pro depends on identity provider groups, so each group that grants console access needs a named owner and a review interval set by your access policy. Remove users who have left or changed teams, and check that no group carries more privilege than its members need. Record each review and its outcome.

Rotate the OIDC client secret

The OIDC client secret used between the Security Onion Console and your identity provider should be rotated on the schedule your policy sets. Plan the rotation window so the new secret is applied to the console and the old one is revoked without locking out analysts. Confirm with the identity provider vendor how overlapping secrets are handled during rotation.

Test the break-glass account

Keep a local break-glass account that works when the identity provider is unreachable, and store its credentials under dual control. Test it on a schedule to confirm it still signs in, that its password is current, and that its use triggers an alert. Record each test so auditors can see the control operates.

Track Pro subscription term end dates

Security Onion Pro is sold on 1 to 5 year terms, and OIDC single sign-on is one of the Pro features. Record the term end date for each deployment and confirm with Security Onion Solutions what happens to SSO and support at expiry before it arrives. Build renewal into your budget and change calendar.

Document identity provider and lockout runbook

Keep current records of the identity provider configuration, the owner of each role mapping, and the runbook for lockouts, including who can reset accounts and how to reach the break-glass path. Store these records where the on-call team can reach them during an outage. Review them after every identity provider or Security Onion change.

Retest SSO after every soup upgrade

Security Onion updates are applied with the soup process, and each update can change how the Console handles authentication. Retest the OIDC sign-in, group-to-role mapping and break-glass path on a matching test grid before production. Support for each version follows the Security Onion EOL dates, so plan upgrades before a release reaches end of life.

What do buyers ask before setting up Security Onion SSO?

Is single sign-on included in the free Security Onion edition?

No. The free edition uses local console accounts, and OIDC single sign-on to the Security Onion Console is a Security Onion Pro feature. Pro is a paid edition that also adds LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API and professional support. If your analysts sign in with corporate identities today, plan for Pro, or keep local accounts with a documented process for creating, reviewing and removing them. Confirm the current feature list on the Security Onion Pro page before you commit, because editions can change between releases. DeployOpen can plan and implement the OIDC integration in your environment once you hold a Pro license.

How much does Security Onion Pro SSO setup cost?

The Pro license and the implementation are separate costs. Pro is a paid edition sold on 1 to 5 year terms, and its price comes from Security Onion Solutions, so check the current terms on its Pro page. DeployOpen quotes the implementation from a written scope. That quote depends on how many identity providers, groups, roles and environments are involved, and on whether you need a test grid that matches production. The implementation is a one-time cost, while the license recurs with each term. Group reviews and secret rotation are ongoing tasks that either your team or a support retainer covers. Ask any quote to list these items separately and to state which environments and identity providers it covers.

How long does OIDC single sign-on setup take?

The duration depends on three factors: how ready your identity provider is, how well your analyst groups are designed, and how many environments need the integration. A tenant with clean groups and a named admin contact moves faster than one where role mapping must be agreed first. DeployOpen does not give a fixed duration before the scope is known. Ask for a written scope that lists the identity provider, the production and test environments, the role mapping, the acceptance tests and the sign-off points. Treat any timeline that lacks those inputs as an estimate that needs to be confirmed. Build in time for at least one round of changes to role mapping, because group owners often refine their requirements once they see the test results.

What does our team need to provide for SSO setup?

The work needs four inputs from your side. First, administrative access to the identity provider, or a named admin who can create the OIDC client and the group claims. Second, group owners who confirm which people belong in each Security Onion role. Third, a test grid that matches the production layout closely enough to prove sign-in and role behavior before rollout. Fourth, written sign-off on the role mapping before anything reaches production. If one of these inputs is missing, the project usually stalls at the first decision that depends on it. Name the owners for each input before kickoff, and agree on who can approve changes to role mapping during the project.

Can our internal team set up Security Onion OIDC without a partner?

Yes, if your team can follow the Pro documentation and test the result thoroughly. The configuration itself is contained, but most of the risk sits in role mapping, claim handling and rollback. An internal team needs an identity engineer, a Security Onion operator who can work with the console and the grid, and a test environment where a failed sign-in does not lock out analysts. Confirm that your team can rehearse a rollback to local accounts before the change reaches production. If those people are not available, or the team has not tested identity provider changes before, a fixed-scope engagement can cover the setup and acceptance testing while your staff learn the configuration.

What changes after OIDC single sign-on goes live?

Ongoing work moves from setup to access governance. Group membership should be reviewed on a schedule your security policy sets, so that leavers and role changes are reflected in Security Onion. Client secrets and related credentials need rotation, and the rotation steps should be rehearsed on the test grid first. Each Pro upgrade or Security Onion release may affect the integration, so retest sign-in and role mapping after every upgrade. Decide who owns these tasks, and whether a support retainer covers them, before go-live. Write the review cadence and rotation steps into your runbook so they survive staff changes.

Which identity providers work with Security Onion OIDC?

Confirm this before scoping, because the Pro documentation defines the supported OIDC settings. OIDC is a standard, but identity providers handle claims, group data and token lifetimes differently, and those differences decide how roles are mapped. Gather your provider type and version, how it exposes group membership, and whether it can issue the claims the console needs. Also check whether your provider supports the token lifetimes and refresh behavior your security policy requires. DeployOpen can review those details against the Pro documentation during scoping, so the written scope reflects what your provider can actually do.

How does DeployOpen scope, build and hand over Security Onion SSO work?

DeployOpen plans, builds, documents and hands over Security Onion SSO with OIDC inside your own infrastructure, from a written scope agreed before work starts. The work covers the identity provider connection to the Security Onion Console, role mapping for analysts, and the checks and runbooks your team needs to operate it after handover.

How we scope

Confirm whether your grid will use Security Onion Pro, since OIDC single sign-on is a Pro feature and the free edition uses local console accounts.
Record your identity provider, the OIDC settings it can supply, and which analyst groups need console access.
Agree in writing which Security Onion nodes, console URLs and role assignments are in scope, and which are excluded.

How we build

Configure the OIDC connection between your identity provider and the Security Onion Console in a test grid before touching production.
Map identity provider groups to Security Onion Console roles so analysts receive only the access their role requires.
Test login, logout, session expiry and fallback access for a documented set of analyst and administrator accounts.

How we hand over

Deliver a configuration record covering identity provider settings, redirect addresses, role mappings and the change steps performed.
Provide a runbook for adding analysts, removing access, rotating identity provider credentials and recovering console access.
Walk your identity and security staff through the runbook and the test evidence so your team can operate the integration unaided.

How we support

Retain the test cases so role mappings can be rechecked after identity provider changes or Security Onion upgrades.
Offer ongoing support and upgrade work as a retainer, scoped in writing alongside the original engagement.
Confirm with your identity provider vendor and Security Onion Solutions which OIDC settings and supported versions apply to your environment.