Logging

YOUnite Uses Elastic

Younite YOUnite logs directly to elastic Elastic via the elastic restful Elastic RESTtful API.

All activity through the mdm restful MDM RESTful API is logged synchronously, if elastic . If Elastic is down, calls to the api API will fail with forbidden (403) errors. Once elastic Elastic is available again, the API will function again.

All activity in internal services are logged (a?)synchronously. If elastic Elastic is down these the activity in internal services will still succeed, but there will be no logging. This may be changed in the future to use Future considerations may include changing to AMQ so as to not drop log entries if elastic Elastic is down.

All activity on the the message queue for the router will be logged (a?)synchronously, this . This may or may not include the payload, depending on configuration.

Per Resource Indices

Each resource's log entries are kept in separate indices that are created either when the resource is created or when the resource is accessed, depending on the type of resource. Index names always start with "mdm-", this . This is used for both easy identification , and to take advantage of the Elastic's configuration ability to configure elastic to forbid index creation of indexes on the fly when the first data entry is posted to it. This allows the logging system to be in control of creating indices and mappings as needed.

Resource indices are created with the naming pattern "mdm-RESOURCE-UUID" where RESOURCE is the type of resource and, UUID is the zone's public facing UUID identifier. E.g. mdm-zone-a2aaedc7-591a-4761-8e35-da875b1e6ac5

Per User (AuthIdentity) Alias's

Alias's are created for the purposes of grouping indices together for ease of use in creating templates in Kibana for dashboards and views that are available through the younite YOUnite web application.

Alisas names are of the pattern mdm-alias-userUUID where userUUID is the public facing UUID identifier of the authIdentity.

What Gets Logged

Currently The following items are currently logged , for API access, is the :

• date/time

• API path
• resource type (matches the index type, e.g. mdm-zone is resource type zone, mdm-domain is resource type domain)

• resource UUID

• whether the access was allowed or rejected via

• OAuth
• ssoid of the

• OAuth token presented for access

• operation type (GET, PUT, DELETE, etc.)

Currently The following items are currently logged for the resource service layer (, which is internal, used by both the api API and the message router) is , CRUD access to the resource. The ssoid, timetamp,:

• ssoid
• timestamp
• resource type (same as the index type)

• resource UUID

• action (

• CRUD)

The following items are currently logged for the Message Bus/router layer:

• tbd

Either of these current logging entries can be easily extended to log additional request data (the object model being created, updated, etc.) or response data (results object model of a getGET, etc...) for complete auditing of not only who made the modification, but what the modification was. This could be done for the entire resource spectrum , or for only specific resources. If needed, the payload data could be easily logged to separate index requiring extended permissions for access.

TODO - PROVIDE TABLE OF WHAT IS LOGGED AND WHAT IS LOGGED ON A PER/ZONE BASIS VS ENTIRE ECOSYSTEM

How

It Is Secured

Elastic and Kibana are secured via an nginx NGINX proxy that authorizes each request via the OuathOAuth. An OAuth bearer token is carried along on each request via a cookie when the user clicks the link in the application dashboard to bring up a kibana link, displaying a Kibana-based view or dashbord dashboard page. This secures access to elastic Elastic and kibana Kibana from the public internet. If needed, the proxy piece could be integrated with elastic Elastic in a single container to provide tighter security. This was not done in the dev environment , for ease of development and testing, but could be done easily for a stand-alone elastic Elastic server(s).

Kibana

When a user clicks a link to display logging information via kibanaKibana, the url URL is modified as it is passed passes through authorization code in the nginx NGINX proxy. The modification uses the information in the oauth OAuth check_token response to pass along the elastic Elastic alias that kibana Kibana will use to populate the dashboard's data in the dashboard. Access to kibana Kibana is allowed if a user has the correct scope permissions for Kibana access to kibana. By default all users have this scopepermission. Logging information that is displayed/available is controlled through the usage of either the alias for users uuidthe user's UUID, which contains all the indices they have access to, or via kibana Kibana searches hitting specfic specific indices to which the user has direct permissions for directly (also encoded in the oauth OAuth token) .

Elastic

Elastic is secured via the same nginx NGINX proxy that protects kibanaKibana. Permissions to allow read access to an index or are controlled via the same permissions mechanism in the token that is used to allow access for that user a user's access to the younite YOUnite API. If a user has GET or ALL permissions to a zone, they have read-only access to the data in the index in elastic Elastic for the same zone.

Notifications

For more information goto

Highlevel discussion on what sort of notifications get sent out and how we leverage webhooks.