EZGH SSO records events in Trails with eventSource sso.ezghcloud.com.
Management events
Every management API call is recorded like any other API call, with the operation’s name as
eventName, such as CreateUser, SuspendUser, CreateApplication or UpdateAssignments.
The API reference lists the operations; reading the catalog isn’t recorded. Secrets
are never recorded: client secrets, identity provider client secrets, SCIM tokens, provisioning
bearer tokens, and service provider metadata documents.
When EZGH SSO finds an email domain’s verification record, or loses it, it records a service
event, UpdateDomainVerification (userIdentity.type EzghService), naming the domain and its
new status. A custom domain’s status changes are recorded the same way, as
UpdateCustomDomainStatus.
Directory sync
Every change your identity provider makes over inbound SCIM, and every refused
change, is an ApiCall: ProvisionUser, UpdateProvisionedUser, SuspendUser,
ReactivateUser, DeprovisionUser, ProvisionGroup, UpdateProvisionedGroup,
UpdateGroupMembership or DeprovisionGroup. userIdentity is the EzghService
scim.ezghcloud.com, with the SCIM token’s ID as principalId and its name as userName.
resources name the directory and the user or group. Reads, and requests refused with 401,
429 or 503, aren’t recorded.
Provisioning pushes
Each outbound provisioning push that changes something at an application is
a ServiceEvent by the EzghService sso.ezghcloud.com, naming the application and the user or
group: ProvisionUser, DeprovisionUser or ProvisionGroup. A push that stops is recorded once,
with errorCode provisioning_failed. Attribute values are never recorded.
Directory activity
What directory users do at your portal is recorded in your organization too, with
userIdentity.type SsoUser and the directory in resources:
eventName |
Records | eventType |
|---|---|---|
SignIn |
A successful sign-in at the portal | SignIn |
SignInFailed |
A failed sign-in, including for an email address that isn’t a user | SignIn |
MfaChallenge |
A second-factor attempt | ApiCall |
Federate |
A sign-in through an identity provider, or its refusal for a known user | ApiCall |
AuthorizeApplication |
An OIDC grant or a SAML assertion issued, or its refusal (not_assigned, a reused code or refresh token) |
ApiCall |
SignOut |
A sign-out, logout from an application (OIDC or SAML), or a refresh token revoked by its client | ApiCall |
- A failed sign-in for an email address that isn’t a user has
userNameHIDDEN_DUE_TO_SECURITY_REASONS, and the address appears nowhere in the event. - Token refreshes aren’t recorded.
- Passwords, TOTP codes, passkey assertions, authorization codes, tokens, cookies, client secrets, identity provider responses, SAML assertions, NameIDs and attribute values are never recorded.
ezgh trails events --event-source sso.ezghcloud.com --event-name SignInFailed --from 1dConsole access
When a directory user opens the console through console access, the portal
records AuthorizeApplication for the console application (or its refusal, not_assigned), and
the console sign-in is recorded as AssumeBot in signin.ezghcloud.com, with
userIdentity.type SsoUser. A refused sign-in has errorCode none_mapped or not_trusted.
Everything they do in the console, and with the temporary API keys they get, is recorded as the
bot, with the person in userIdentity.sessionContext.sourceIdentity. Getting a temporary API key
is recorded as CreateTemporaryApiKey in signin.ezghcloud.com. See
Console access: Auditing.