[
https://issues.apache.org/jira/browse/SYNCOPE-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zimakov updated SYNCOPE-1981:
----------------------------------
Description:
h2. Background
Every audit event records the principal that *performed* the operation in the
{{AuditEvent.who}} column (NOT NULL, populated on every write). The audit
search API (GET /audit/auditEvents, backed by AuditQuery) currently allows
filtering by {{{}entityKey{}}}, {{{}type{}}}, {{{}category{}}},
{{{}subcategory{}}}, {{{}op{}}}, {{outcome}} and a {{{}before{}}}/{{{}after{}}}
timeframe — but {*}not by {{who}}{*}. There is no way to answer "what did
administrator X do", which is particularly useful when X's account has since
been deleted and its {{entityKey}} (UUID) is no longer known.
h2. Proposal
Add a {{who}} filter to the audit search API that matches the
{{AuditEvent.who}} column, supporting:
* exact match \{who=jsmith}
* multiple values, OR-combined \{who=jsmith&who=admin}
{{who}} composes (AND) with all existing filters. When absent/empty, behavior
is unchanged (fully backward compatible).
h2. Scope
* REST bean ({{{}AuditQuery{}}}), REST impl ({{{}AuditServiceImpl{}}}), logic
({{{}AuditLogic{}}}), DAO interface ({{{}AuditEventDAO{}}}) and *all four*
implementations: JPA, Neo4j, Elasticsearch, OpenSearch.
* Integration tests in {{{}AuditITCase{}}}.
h2. Out of scope
* A general Admin Console audit-search page (a separate, larger feature).
* Adding a database index on {{who}} (optional follow-up; no schema migration
is performed here).
h2. Backward compatibility
Purely additive query parameter; existing clients and queries are unaffected.
No database migration — the {{who}} column already exists and is populated.
was:
h2. Background
Every audit event records the principal that *performed* the operation in the
{{AuditEvent.who}} column (NOT NULL, populated on every write). The audit
search API (GET /audit/auditEvents, backed by AuditQuery) currently allows
filtering by {{{}entityKey{}}}, {{{}type{}}}, {{{}category{}}},
{{{}subcategory{}}}, {{{}op{}}}, {{outcome}} and a {{{}before{}}}/{{{}after{}}}
timeframe — but {*}not by {{who}}{*}. There is no way to answer "what did
administrator X do", which is particularly useful when X's account has since
been deleted and its {{entityKey}} (UUID) is no longer known.
h2. Proposal
Add a {{who}} filter to the audit search API that matches the
{{AuditEvent.who}} column, supporting:
* exact match {who=jsmith}
* multiple values, OR-combined \{who=jsmith&who=admin}
* {{*}} wildcards {who=svc-*}
{{who}} composes (AND) with all existing filters. When absent/empty, behavior
is unchanged (fully backward compatible).
h2. Scope
* REST bean ({{{}AuditQuery{}}}), REST impl ({{{}AuditServiceImpl{}}}), logic
({{{}AuditLogic{}}}), DAO interface ({{{}AuditEventDAO{}}}) and *all four*
implementations: JPA, Neo4j, Elasticsearch, OpenSearch.
* Integration tests in {{{}AuditITCase{}}}.
* Wildcard values are escaped so that only {{*}} acts as a wildcard; all
values are parameter-bound (no SQL / Cypher / regex injection). The JPA
{{LIKE}} predicate uses {{ESCAPE '#'}} for cross-database portability.
h2. Out of scope
* A general Admin Console audit-search page (a separate, larger feature).
* Adding a database index on {{who}} (optional follow-up; no schema migration
is performed here).
h2. Backward compatibility
Purely additive query parameter; existing clients and queries are unaffected.
No database migration — the {{who}} column already exists and is populated.
> Search audit events by who (the principal that performed the operation)
> -----------------------------------------------------------------------
>
> Key: SYNCOPE-1981
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1981
> Project: Syncope
> Issue Type: Improvement
> Components: core
> Reporter: Oleg Zimakov
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Background
> Every audit event records the principal that *performed* the operation in the
> {{AuditEvent.who}} column (NOT NULL, populated on every write). The audit
> search API (GET /audit/auditEvents, backed by AuditQuery) currently allows
> filtering by {{{}entityKey{}}}, {{{}type{}}}, {{{}category{}}},
> {{{}subcategory{}}}, {{{}op{}}}, {{outcome}} and a
> {{{}before{}}}/{{{}after{}}} timeframe — but {*}not by {{who}}{*}. There is
> no way to answer "what did administrator X do", which is particularly useful
> when X's account has since been deleted and its {{entityKey}} (UUID) is no
> longer known.
> h2. Proposal
> Add a {{who}} filter to the audit search API that matches the
> {{AuditEvent.who}} column, supporting:
> * exact match \{who=jsmith}
> * multiple values, OR-combined \{who=jsmith&who=admin}
> {{who}} composes (AND) with all existing filters. When absent/empty, behavior
> is unchanged (fully backward compatible).
> h2. Scope
> * REST bean ({{{}AuditQuery{}}}), REST impl ({{{}AuditServiceImpl{}}}),
> logic ({{{}AuditLogic{}}}), DAO interface ({{{}AuditEventDAO{}}}) and *all
> four* implementations: JPA, Neo4j, Elasticsearch, OpenSearch.
> * Integration tests in {{{}AuditITCase{}}}.
> h2. Out of scope
> * A general Admin Console audit-search page (a separate, larger feature).
> * Adding a database index on {{who}} (optional follow-up; no schema
> migration is performed here).
> h2. Backward compatibility
> Purely additive query parameter; existing clients and queries are unaffected.
> No database migration — the {{who}} column already exists and is populated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
