Page History

The container and container application MUST log the field “date/time” in the security audit logs. 

The value should be represented in UTC and formatted per ISO 8601, such as “2015-06-03T13:21:58+00:00”. The time should be shown with the maximum resolution available to the logging component (e.g., milliseconds, microseconds) by including the appropriate number of decimal digits. For example, when millisecond precision is available, the date-time value would be presented as, as “2015-06-03T13:21:58.340+00:00”.

R-97445

v1.3 Spec

CON-LOG-REQ-8

The container and container application MUST log the field “protocol” in the security audit logs.

This refers to the communication mechanism for a request.  The value of this field should be represent the OSI application layer  protocol.

QUESTION: Should this be a human readable value like HTTP or the port number like 80?

What are you trying to do.  What URL were you trying to hit when doing this.

Could be presented as an enum (HTTP, HTTPS, SSH, etc).  THis is the OSI application layer protocol.  

This is the communication mechanism.

R-25547

CON-LOG-REQ-9

The container and container application MUST log the field “service or program used for access” in the security audit logs.

This intention is to capture the service name endpoint or a externally advertised API invoked, i.e., where are you connecting to. This is represented as a URI or URL. 

The URI that the caller used to make the call to the component that is logging the message. (The service inside the partner doing the call - includes API name)

Externally advertised API invoked by clients of this component

For Audit log records that capture API requests, this field contains the name of the API invoked at the component creating the record (e.g., Layer3ServiceActivateRequest).

For Audit log records that capture processing as a result of receipt of a message, this field should contain the name of the module that processes the message.

R-06413

v1.3 Spec

(4)

CON-LOG-REQ-10

The container and container application MUST log a "status code" in the security audit logs. 

This field indicates the high level status for transactional events.  It must have the value COMPLETE when the request is successful, ERROR when there is a failure, and INPROGRESS for states between the COMPLETE and ERROR.

REMOVE: ResponseCode: This field contains application-specific error codes.
REMOVE: ResponseDesc: This field contains a human readable description of the ResponseCode

R-15325

v1.3 Spec

The container and container application MUST log the field “Login ID” in the security audit logs. 

The container and container application MUST log the Principal identity of the entity accessing the service (e.g., Login ID, NPE, Token,  etc.)

NOTE:  This seems similar to PartnerName in the v1.3 spec

This field should contain the name of the client application user agent or user invoking the API.

This is often used for heuristic analysis to identify invocations between ONAP individual ONAP components. Its value has never been clearly stipulated, so a common problem has been a lack of consistency. 

There is no clear consensus, but:

• Use the short name of your component, e.g. xyzdriver. 
• Values should be human-readable. 
• Values should be fine-grained enough to disambiguate subcomponents where it's likely to matter. This is subjective. 
• Be consistent: your component should ALWAYS report same value. 

Real-life examples include MSO, bpmnclient, BPELClient, (all of which are reported by SO), openECOMP (SDNC), vid (VID!) etc. (See the problem?)

From (4): This field contains the name of the client or user invoking the API in the prior field, if known.

The identification of the entity that made the request being served.  For a serving API that is authenticating the request, this should be the authenticated username or equivalent (e.g. an attuid or a mechid)

1. If an authenticated API, then log the userid
2. Otherwise, if the HTTP header "X-ONAP-PartnerName" was provided, then log that (note: this was a direction that we seemed to be going but never completed)
3. Otherwise, if the HTTP header "X-FromAppId" was provided, then log that
4. Otherwise, if the HTTP header "User-Agent" was provided, then log that
5. Otherwise, log "UNKNOWN" (since the field is currently required, something must be in it)

R-89474

v1.3 Spec