Integrations: ITSM, SSO, LDAP and SIEM

Integration	Connects to	What it does
Ticketing (ITSM)	ServiceNow, Jira, generic REST	Checks the ticket at save and at execution, stops on a closed or unapproved ticket and writes events back to the ticket as notes.
Corporate sign in (SSO)	OIDC: Entra ID, Keycloak, Okta SAML 2.0: AD FS, Entra ID, Keycloak	The password never reaches the product. The product role comes from the group in your identity provider.
Directory (LDAP) and second factor	Active Directory, standard LDAP directories	The password is checked in the directory, roles come from groups and an account disabled in the directory cannot sign in here either. A time based code can be enabled as a second factor.
SOC and SIEM	Syslog (TLS, TCP, UDP) and file CEF, LEEF, RFC 5424, JSON	Streams audit events over TLS or TCP; an event that cannot be delivered is not skipped and is retried on the next round. Narrowing the scope is allowed; hiding that you narrowed it from the SOC is not.

The ticketing, identity and directory connections ship switched off; SIEM delivery does not start until an endpoint address is defined. The Governance Setup Check screen shows the state of each. Turning them on is your decision.

Ticketing

The ticket was approved. Is the work that runs tied to that ticket?

The change advisory board (CAB) approves a ticket, but the script that will run is not in it, and the record may have been closed or withdrawn after approval. The product closes that gap at two points.

1. When the request is saved

The number is looked up in your ticketing system. If the record does not exist, is of the wrong type or is already closed, the request is not saved. There are three modes: off, warn and block. The default is block.

2. At the moment of execution

The same ticket is asked again. No cache is used, because approval may have been withdrawn after the job was queued. If the change record is not in an executable state, the work does not start. The request does not die: it stays approved and runs again once the record is ready.

Each request type maps to its record in the ticketing system

Request in the product	Record in the ticketing system	Rule
Change	Change record	Must exist, be of the right type and be in an executable state. Enforcing the planned window is optional.
Query result (data extraction)	Service request	Must exist, be of the right type and not be closed. Asking for data is not a change, so no CAB approval is required.
Emergency request	Incident record	Emergency approval is usually given afterwards, so CAB approval is not required. A closed or missing change record still stops the work; the incident number check is in warn mode by default and can be set to block. Every emergency execution that passes is written down as an exception.
Rollback	The source change's record	Exempt from the gate: the source record may already be closed, and locking a rollback would block the repair of a broken production system. The exemption is recorded.

The write direction: what the product does shows up in the ticket

When a request is opened, approved, rejected, scheduled, executed or fails, a short note is added to the ticket (a work note in ServiceNow, a comment in Jira). The note text is fixed and plain: it contains no script text, no result data and no password. If the ticketing system cannot be reached, the note is not lost; the next round resumes from the same place. A note that cannot be delivered for a long time raises a single alert event that goes to the SOC.

What happens when the ticketing system is off or unreachable

While it is off the request checks the ticket number against the format rule only. The integration ships switched off.
When it cannot be reached you choose one of two options: stop the work, or let it continue while the failed check is recorded and an alarm goes to the SOC. The default is the second. An unreachable ticketing system does not lock an emergency request.
For a scheduled job, cases where the gate will certainly stop it at run time are caught while you schedule it, so you do not learn about a stalled night job from an email in the morning.

What it shows the auditor

The record the product saw at that moment (state, type, approval field) is frozen into the audit trail as it was. Even if the record in the ticketing system changes later, the answer to "what was seen that day" is not lost. A ticket that breaks the rule, a record that could not be verified, an execution stopped at the gate or passed without CAB approval, and notes that could not be delivered are written under their own event names and reach the SOC regardless of the filter.

Connectors and setup

ServiceNow: change, incident and service request records through the Table API. Jira: REST v2 and v3; email and API token in the cloud, a personal access token on a data center installation. Generic REST: the lookup and note addresses are defined as templates, so another ticketing system can be used too. Connection settings live in the application settings file, secrets stay on the API server only, and certificate validation is on by default. On the Settings > ITSM screen "Test connection" looks up a real record. The connectors were tested end to end against a lab simulator that imitates the real response shapes of these three systems; we verify them together with you against your own instance at first setup.

Corporate sign in

The password never arrives here, the role comes from the group

A "Sign in with your corporate account" button appears on the sign in screen. The user types the password and the second step on the identity provider's own page; the product only verifies the signed answer.

Two protocols

OpenID Connect (authorization code flow with PKCE): Microsoft Entra ID, Keycloak, Okta. SAML 2.0 (HTTP-POST): AD FS, Microsoft Entra ID, Keycloak. More than one provider can be defined at once; a misconfigured provider is not used and does not affect the others or local sign in.

The role is assigned from the group

Groups in your identity provider are mapped to product roles. If several groups match, the highest role wins. If none matches, the person does not get in. The system manager role is never granted by a mapping; it is always assigned deliberately inside the product. An organisation that prefers to manage roles by hand can turn the mapping off.

A leaver is closed in one place

When the account is closed in your identity system, no new session can be opened. When a user's sessions are closed inside the product, the access token they still hold is rejected on the next request; it does not have to wait for its expiry.

The emergency sign in stays visible

If someone signs in with a local password while corporate sign in is on, it is written as a separate event and goes to the SOC as an alarm. The auditor sees "who signed in locally while SSO was on" on a single line.

Setup and verification status

Providers are defined in the application settings file; the API is restarted to apply a change. Automatic account creation on first sign in, session length and sign out from the identity provider are configurable. Addresses and SAML metadata are shown on the setup screen in copyable form. OpenID Connect and SAML were verified end to end against a local Keycloak and with automated tests. Setup steps for Entra ID and AD FS are ready and they use the same standard protocols; we verify them with you against your own tenant at first setup.

Directory and second factor

Your directory stays the source of identity

If you have no identity provider, or prefer to talk to the directory directly, Active Directory and standard LDAP directories are supported. The connection was tested end to end, with automated tests, against a test directory over LDAPS and StartTLS; we verify it with your Active Directory at first installation.

The password is checked in the directory. It is not kept in the product. The connection is encrypted with LDAPS or StartTLS; certificate validation is skipped only if you explicitly allow it. An empty password is never sent to the directory, because on many directories an empty password bind counts as an anonymous sign in and succeeds.
Roles come from groups. Nested groups are read; a read error never lowers a role, because a partly read list would quietly cut someone's access. Mapping can use the full name or the short name.
An account disabled in the directory cannot sign in here either. A background job sets accounts that are disabled or missing in the directory to no access. The last system manager is never closed this way. If the sync hits its mass disable limit or cannot reach the directory, it stops without changing anything and that goes to the SOC as an alarm.
Second factor. A time based one time code (authenticator app) is supported. "Second factor on" is not the same as "everyone uses it": mandatory enrolment is a separate setting. While it is on, the session of a user who has not enrolled works only for the enrolment step and for nothing else.

SOC and SIEM

The evidence sits in two places: in the product and in your SOC

The audit trail already sits in a tamper evident record. The SOC integration streams a copy of it into your own security system, in your own format. The decision is made in the product and your security team also sees the record on its own platform; it does not have to take the product's record on trust.

Four streams, two mechanisms

The audit (Audit) and ledger digest (Anchor) streams are read from the audit record table and advance with a "sent up to here" marker. If delivery fails the marker does not move and the next round resumes from the same place: nothing is lost. (UDP is the exception: it drops a message that does not fit one packet and does not say so, which is why TLS is recommended.) The application log goes through an in memory queue and, when the queue is full, the oldest record is dropped: loss is possible on this stream, and deliberately so. The heartbeat is a liveness signal.

Five formats, two transports: syslog and file

Formats: RFC 5424 with JSON (default), CEF (ArcSight), LEEF (QRadar), plain JSON and RFC 5424 structured data. Transports: syslog over TLS (recommended), TCP and UDP, plus a line by line JSON file for organisations with no collector. More than one endpoint can be defined and each keeps its own marker. On TLS, if a server certificate thumbprint is set, a connection that does not match is refused and the product never falls back silently to plain text.

You can narrow the scope, you cannot hide it

SIEM licences are priced by volume, so you choose which streams and which severity threshold go out. But five classes go out whatever the threshold: actions that change or loosen controls (identity and permission changes included), emergency actions and ticketing exceptions, denied permissions and failed sign ins, ledger digest events (a digest published or failed, a restore), and the evidence write boundary breaking or being restored. Every change to the filter also reaches the SOC as a separate announcement.

What leaves, and what does not

Only permitted fields enter a message; any field that is not recognised does not go. Facts that help classify an event, such as which server, which risk band and how many statements, go out; which rows came back does not. Script text is not sent to the SOC by default; sending it is a separate setting.

The Diagnostics, SOC and SIEM screen: defined endpoints, target, format, streams, threshold, lag and time of the last delivery — **Endpoint health** For each endpoint: target, format, streams, threshold, lag and time of the last delivery.

Two syslog lines arriving at the SOC collector: a Siem.FilterChanged event showing which streams the filter closed and reopened — **The announcement of narrowing** When a stream is removed from the filter, a Siem.FilterChanged event reaches the collector: old and new value together.

Topic	How it works
Where it is configured	Connection details (address, protocol, secrets) live in the application settings file. Filter and policy decisions are parameters on the Settings screen; a change is written to the audit trail and, if settings approval is on, goes through four eyes approval.
Setup check	The Governance Setup Check screen lists whether each integration is on or off, and any configuration errors. A faulty setting is never used silently.
Setup time	Step by step setup and the integration settings are described in the Installation and Operations document. The prerequisites list says in advance which accounts, certificates and ports are needed.

It sits next to the tools you already run: ticketing, identity and your security event platform