oidc audit log

[Cantor, Scott]

On 4/21/22, 8:55 AM, "users on behalf of Pavlik Martin" <users-bounces at shibboleth.net on behalf of martin.pavlik at upol.cz> wrote:

>    OIDC plugin uses standard shibboleth logs. We use shib-idp-auditlog plugin for statistic of logins but with

The auditing is for tracking every request into each specific endpoint supported, but you can also supress specific profile/endpoint events in the documented way in audit.xml. But it's not meant to track authentication, because that's just a byproduct of specific endpoints, it's not the core event being audited, ever. You have logs in your authentication systems that are better used for that purpose. The IdP's audit log is auditing the IdP's events, not login events.

>    There is audit.log with OIDC authentication. It contains 4 lines to successfully authenticate user for one RP:

You would have to take that up with the people who designed OIDC. I think it's rather bonkers myself. Certainly is an interesting definition of "simpler".

>    1. Is it possible to use separate logs for OIDC processes ? 

The audit log is sent to logback like any other logging. The Appender(s) used are up to you. The logging category used is actually a combination of a key from the audit formatting map in audit.xml (you can have multiple such formatting strings) combined with an endpoint-specific (and configurable) logging "ID", which makes up the full category.

SAML for example logs events under Audit.SAML2.SSO and such by default. The Audit part comes from the map and the SAML2.SSO part is the default logging ID for SAML 2 SSO. So that's the full category and a logger can route that differently than SAML1.SSO, etc.

 So from a logback point of view you can route specific categories to different appenders, rather than just rely on the default behavior.

You can also turn things off endpoint by endpoint, as the defaults do, e.g., not logging requests to the status endpoint. The shibboleth.AuditSuppressedProfiles bean can turn things off by profile URI, which are values documented in the wiki for each profile. That's somewhat cleaner than routing a logger to a null appender or something.

>    2. Is it possible to log only one line UserInfoRequest into audit.logs ?

There is only one line for the UserInfo endpoint event. But that's only one of the steps in OIDC.

>    3. There are in audit.xml and logback.xml customized settings for OIDC loging ?

Audit logging configuration is based mostly on fields, not protocols. There are some fields specific to OIDC (don't know if they're documented yet) and a lot of others that overlap with the other protocols, but there is a ton of work to do to make the audit logging useful for OIDC, it took me many iterations to get the SAML logging relatively complete and it's always a work in progress.

But then the logback configuration can be used to configure different appenders not by protocol but by profile/endpoint/flow, regardless of the fields being logged.

There were also corrections made to a lot of this in the 3.1 plugin to get the logging categories cleaned up and configurable via property like the SAML ones are, though there's not a lot of call to really need to change them. But they are somewhat different in 3.1 so I wouldn't play a whole lot until you're current.

-- Scott