...
| Contact | Item | Type | Currently Available? | |||
|---|---|---|---|---|---|---|
| TIER | Software Version(s) | Gauge | Java and IdP versions are in the process log and status page but not in a structured way. Nothing else is really captured (container, OS, connected systems). | |||
| TIER | Authentication Attempts | Counter | Audit log exposes authentications in terms of requests for profiles that involve authentication (i.e. SSO), and time of authentication could be used to extrapolate whether an actual act of authentication occurred. Failed authentication frequently never exits the IdP or produces any audit trail. | |||
| TIER | Attributes Released | Gauge | In audit log on a per-transaction basis. Not clear from TIER requirements whether this is about particular transactions or some kind of inquiry into policy at IdP. | |||
| TIER | Attribute filter rules on a per-attribute basis | Gauge | ||||
| TIER | Metadata sources list and whether or not signature verification enabled for each | Gauge | Available now in status page but unstructured, except for the signature verification, which is a filter. APIs look like they do provide access to the filters installed, so a status page replacement could do this. | |||
| TIER | Heap size (max, usage, available) | Histogram | Available as a gauge in status page, so could be polled and tracked over time. | |||
| TIER | MDQ service response time | Timer | ||||
| Scott Cantor | Metadata processing time | Timer | Applies to all stages of metadata processing, filtering, etc, and might be interesting to include heap gauge also | |||
| Scott Cantor | Request processing time | Timer | Definitely beginning to end, though need to account for the cases where the user's in the middle somehow | |||
| Scott Cantor | Request counter | Counter | Should be able to emit counters of various types (requests for various profiles, maybe counters of individual RPs or users or logins or sessions) | |||
| Scott Cantor | Expensive operation timings | Timer | Need to assess any places we'd like to gather indications of bottlenecks, certainly would include attribute resolution, scripts, connectors, authentication |
Architecture
Logging should continue to be a significant piece of this conversation, because it is obviously not realistic for the IdP to keep a permanent record of all of the things that it does (particularly when there is no requirement for any persistent storage in a lot of deployments to begin with). Any requirements for truly accurate time-series information about requests and things that would normally be audited seem to be better handled through log analysis, but this may include the production of new logging streams, or audit logging formats, that are more suitable for analysis for particular audiences.
...