For auditing purposes

SVS tech log - check!

  1. Incoming Authentication request from RP
  2. Entity id of IdP selected by the user: response returned from the discovery server
  3. Authentication request/response to/from IdP
  4. Authentication response delivered back to RP

SVS anonymised log

  1. All transactions of a specific IdP
  2. All transactions of a specific SP
  3. Transactions per SP and IdP

Log error situations as well -> Yes! Niels provides more requirements, but not now.

MDQ log

  1. Incoming request + outgoing response

Identified challenges

  • Logging across multiple nodes
    • Two critical points: the response from discovery server and the response from IdP can be delivered to different SVS nodes.
    • How to track one "transaction" (the entire flow from the authentication request from an RP all the way to response back to the RP) across (possibly) multiple nodes?
      • Assign each transaction a unique transaction id at the node which first receives the authentication request from an RP.
      • Can UUID be used (is it thread-safe, is its Python implementation really unique across space and time): http://tools.ietf.org/html/rfc4122.html?
  • Are there additional requirements, e.g. from law enforcement?
  • How to format the logs?  "Apache" format
  • Log rollover -> Do not deal with it, leave this to the Operating System (logrotate deamon).
    • SVS tech log: ~1 day
    • MDQ log: ~1 day
    • SVS anonymised log: >1 year (depending on local law)
  • Storage format
    • Database for SVS tech log + MDQ log to allow faster filtering and deletion of old data
      Get rid of it asap. Filtering afterwards is sombody elses problem.
    • SVS anonymised log?
      Niels provide example
    • Backup of logs (maybe distributed somewhere else)?
      Use Rsync, not a problem.
  • Handle log failure
    • How to detect? -> Do not, this is (for now a problem of external monitors)
    • Can we allow a node to continue operation if it can't log, or are the logs considered critical for operation (they should be since we cannot guarantee/prove anything without logs)?
  • Future: how to filter and present the logs in the admin interface, how to protect the logs (can't publish them publicly at every node)?
  • No labels