...
| 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 | GaugeTimer | |
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.
...