Page Comparison

Field extraction is the process of populating a labeled field in an AuditContext object that is built up over the life of a transaction. The context is just a map of field names to collections of values and the field names are just conventions built-in to the software to provide a standard set of useful fields to audit.

Fields are extracted at various points through the life of a transaction so that adequate detail can be exposed about the request, the processing of the request, and the response. These extraction points are associated with collections of field extraction beans that do the actual work to pull data out of the state of the transaction and store it for output.

The built-in extraction points and beans are as follows (empty beans are not provided to reduce clutter, but you can add them, per the example below):

1. shibboleth.FlowStartAuditExtractors

   • Extractors that run immediately after the flow starts operating and the ability to add fields is possible

2. shibboleth.PostDecodeAuditExtractors

   • Extractors focused on the input message, runs after decoding the input message

3. shibboleth.PostLookupAuditExtractors

   • Runs after establishing the sender's identity, supplements the input side with information about the relying party

4. shibboleth.PostAssertionAuditExtractors

   • Extractors focused on authentication, session, and attribute information, runs after those processes and after the initial creation of the outgoing assertion (if relevant to the request)

5. shibboleth.PostResponseAuditExtractors

   • Extractors focused on the outgoing message, runs after construction of the message

6. shibboleth.LogoutRequestAuditExtractors

   • Extractors focused on information specific to a SAML LogoutRequest message, runs after decoding of the message

7. shibboleth.LogoutAuditExtractors

   • Extractors focused on information in a non-SAML logout

8. shibboleth.ErrorViewAuditExtractors

   • Extracts subject, session, and attribute information, runs in the event that a local error is generated

9. shibboleth.consent.PreConsentAuditExtractors

   • Extracts basic information about the consent step, runs before a decision is made

   • Empty map beans are declared in conf/intercept/consent-intercept-config.xml

10. shibboleth.consent.ConsentAuditExtractors

    • Extracts information about the decision, runs after a decision is made

    • Empty map beans are declared in conf/intercept/consent-intercept-config.xml

11. shibboleth.PostRequestAuditExtractors

    • Extractors for an AuthnRequest built for proxied SAML SSO

12. shibboleth.PostInboundResponseAuditExtractors

    • Extractors for a Response from proxied SAML SSO

13. shibboleth.PostInboundAssertionAuditExtractors

    • Extractors for Assertions from proxied SAML SSO

Each entry in these maps is a key containing the string label to associate (the name of the field), and a value containing a Function<ProfileRequestContext,Object> instance. Functions can return either single objects that get converted to a string for logging, or a Collection of objects that are converted to strings and separated by commas within the logged field.

In this manner, you can add your own fields by implementing a function (or writing a script) to return any data you can find in the context tree and associating it with a custom field label by adding it to one of the maps named above.

A similar extractor map exists for each login flow in the IdP, allowing different auditing behavior per-flow. All these beans have names based on the underlying login flow (e.g. shibboleth.authn.Password.AuditExtractors, etc.)