Support for authentication logging enrichment #1297
Conversation
| # When a user successfully authenticates and additional logging to the authentication log is desired, the following | ||
| # parameter can be used to define a mapping of attributes that will be used to enrich the authentication log. | ||
| # A (list) mapping is for example <attributeLabel>: <attributeName> where the label represents the label that is | ||
| # used in the authentication log record. The attributeName will be searched in the response attributes and if present |
There was a problem hiding this comment.
Maybe clarify what "response attributes" means here. Is it the final attribute value after ARPs, Manipulation and such?
There was a problem hiding this comment.
It is indeed after ARP and Manipulation, I have added it to the description
|
I like the idea, it's a straightforward and yet flexible approach to allow deployers to log something that is specific to their interest. |
| $logAttributes = []; | ||
| if (!empty($this->configuredLogAttributes)) { | ||
| foreach ($this->configuredLogAttributes as $attributeKey => $attributeValue) { | ||
| if (!empty($this->_responseAttributes[$attributeValue])) { |
There was a problem hiding this comment.
Have you considered a (arguably) more expressive array_key_exists here? I assume the value is always set when the key exists.
There was a problem hiding this comment.
Thanks, implemented the change and did a little refactoring to the variables as well
| 'engine_sso_endpoint_used' => $engineSsoEndpointUsed, | ||
| ]; | ||
| if (!empty($logAttributes)) { | ||
| $logData = array_merge($logData, $logAttributes); |
There was a problem hiding this comment.
The attributes now end up as $logData entries. From a log-audit perspective it might be more 'friendly' to bundle them in a new array.
$logData = [
'login_stamp' => $timestamp,
....
'engine_sso_endpoint_used' => $engineSsoEndpointUsed,
'response_attributes' => $logAttributes
There was a problem hiding this comment.
Implemented the change, thanks!
There was a problem hiding this comment.
Now it's always added even when empty. Maybe better to only add the key if the value is non-empty?
There was a problem hiding this comment.
Updated this part :)
Hi all,
With these changes we would like to contribute support for enriching the authentication logging. For some context, this refers to the logging done with 'login granted' where information such as timestamp, SP, IdP etc. is logged. These changes allow the configuration of a mapping in parameters.yml to enrich the logging information with response attributes.
The mapping consists of a label and the name of attribute that is desired e.g. in parameters.yml:
Default value is empty array.
The logging would then look like
authentication.INFO: login granted {"login_stamp":"2024-04-26T12:02:42.904740+02:00","user_id":"","sp_entity_id":"","idp_entity_id":"","key_id":null,"proxied_sp_entity_ids":[],"workflow_state":"prodaccepted","original_name_id":"3d264e07006590d060e96c618e8fafc13a6d21a1","authncontextclassref":"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport","requestedidps":[],"engine_sso_endpoint_used":"https://engine/authentication/idp/single-sign-on", "myLabel1":"value1","myLabel2":"value2"} {"session_id":"0gd53uec0mc4g1ohcneq6mo6s6","request_id":"662b7bb806f3e"}