Audit Events: `saml.created` event should include the SAML connector

[jof]

What would you like Teleport to do?

When SAML connectors are changed, the audit log is a bit sparse. Teleport should reflect the changes, or complete SAML metadata/spec document into the saml.created audit record.

Teleport should probably explicitly exclude some sensitive fields like signing_key_pair.private_key from the Audit log, and perhaps just log that the field changed at all.

What problem does this solve?

When auditing a Teleport cluster from historical information in the log, it is important to be able to reason about the state of the authentication configuration at any point. Without the critical SAML connector information in the audit log, there is not a way to reconstruct historical state. It could be possible for an administrator with access to update SAML connectors to install a malicious SAML connector config to a new IdP, log in maliciously as another Teleport User, and alter privileged cluster configuration. (As a privilege escalation) Afterwards, by setting the SAML connector back to the old values, it could be possible to evade detection.

If a workaround exists, please include it.

It might be possible to (ab)use the Teleport APIs to regularly export and log changes to important resources like SAML connectors (but leaves open the possibility of timing and race attacks)

[zmb3]

When auditing a Teleport cluster from historical information in the log, it is important to be able to reason about the state of the authentication configuration at any point.

This is a much larger feature request than just SAML. Teleport does not store the history of any resource, so reasoning about the state of auth configuration at any point would also require you to know the state of all roles, cluster auth preference, MFA devices, etc.

[jof]

It is very true that to fully reason about the full state of cluster, we would need to capture and emulate a lot more information sources.

However, it was my hope in this request to just capture fields that have changed (or all fields) in the SAML connector spec. Currently, just looking at the audit log, there is no way for us to differentiate day-to-day updates to the attributes_to_roles list vs. something more foundational and impactful like updates to the entity_descriptor or signing_key_pair.