APEREO CASDocumentation

Enterprise Authentication for All Earthlings and Beyond

Identity, Single Sign-On and Access Management
View on GitHub

Audits

CAS uses its own Inspektr framework for auditing purposes and statistics. This framework used to be a separate project and lived outside the codebase previously and has since been merged entirely into the CAS codebase. The Inspektr components allow for non-intrusive auditing and logging of the coarse-grained execution paths e.g. Spring-managed beans method executions by using annotations and Spring-managed @Aspect-style aspects.

CAS server auto-configures all the relevant Inspektr components. All the available configuration options that are injected to Inspektr classes are available to deployers via relevant CAS properties. Note that the audit record management functionality of CAS supports handling multiple audit record destinations at the same time. In other words, you may choose to route audit records to both a database and a REST endpoint as well as any number of logger-based destinations all at the same time.

The following settings and properties are available from the CAS configuration catalog:

cas.audit.engine.abbreviation-lengthAbbreviate fields and entries in the audit logs where possible by the given length.
100

Abbreviate fields and entries in the audit logs where possible by the given length. This typically is applied to long service URLs that are captured in audit logs. Negative/Zero values disable the abbreviation altogether.

Type
Integer
Default
100
Defined by
AuditEngineProperties
cas.audit.engine.alternate-client-addr-header-nameRequest header to use to identify the client address.
X-Forwarded-For

Request header to use to identify the client address.

If the application is sitting behind a load balancer, the client address typically ends up being the load balancer address itself. A common example for a header here would be X-Forwarded-For to glean the client address from the request, assuming the load balancer is configured correctly to pass that header along.

Type
String
Default
X-Forwarded-For
Defined by
AuditEngineProperties
cas.audit.engine.alternate-server-addr-header-nameRequest header to use identify the server address.
no default

Request header to use identify the server address.

Type
String
Default
none
Defined by
AuditEngineProperties
cas.audit.engine.audit-formatThe audit format to use in the logs.
DEFAULT
The audit format to use in the logs. Available values are as follows:
  • DEFAULT: Default audit format.
  • JSON: Output audit logs as JSON strings where necessary/possible.
Type
AuditEngineProperties.AuditFormatTypes
Default
DEFAULT
Defined by
AuditEngineProperties
cas.audit.engine.enabledWhether auditing functionality should be enabled.
true

Whether auditing functionality should be enabled.

Type
Boolean
Default
true
Defined by
AuditEngineProperties
cas.audit.engine.excluded-actionsIndicate a list of supported audit actions that should be excluded, filtered and ignored by CAS audit managers.
no default
Regex

Indicate a list of supported audit actions that should be excluded, filtered and ignored by CAS audit managers. Each supported action can be treated as a regular expression to match against built-in CAS actions.

Type
List<String>
Default
none
Defined by
AuditEngineProperties
cas.audit.engine.http-request-headersCollection of HTTP headers that could be extracted from the request and tracked by the underlying audit engine and storage.
no default

Collection of HTTP headers that could be extracted from the request and tracked by the underlying audit engine and storage. By default, all request headers are tracked and stored.

Type
List<String>
Default
none
Defined by
AuditEngineProperties
cas.audit.engine.ignore-audit-failuresIndicates whether catastrophic audit failures should be logged or whether errors should bubble up and thrown back.
false

Indicates whether catastrophic audit failures should be logged or whether errors should bubble up and thrown back.

Type
Boolean
Default
false
Defined by
AuditEngineProperties
cas.audit.engine.include-validation-assertionWhether ticket validation events in the audit log should include information about the assertion that is validated; things such as the principal id and attributes released.
false

Whether ticket validation events in the audit log should include information about the assertion that is validated; things such as the principal id and attributes released.

Type
Boolean
Default
false
Defined by
AuditEngineProperties
cas.audit.engine.number-of-days-in-historyRetrieve audit records from storage, starting from now and going back the indicated number of days in history.
30

Retrieve audit records from storage, starting from now and going back the indicated number of days in history.

Type
Integer
Default
30
Defined by
AuditEngineProperties
cas.audit.engine.supported-actionsIndicate a list of supported audit actions that should be recognized, processed and recorded by CAS audit managers.
no default
Regex

Indicate a list of supported audit actions that should be recognized, processed and recorded by CAS audit managers. Each supported action can be treated as a regular expression to match against built-in CAS actions.

Type
List<String>
Default
none
Defined by
AuditEngineProperties
cas.audit.engine.use-server-host-addressDetermines whether a local DNS lookup should be made to query for the CAS server address.
false

Determines whether a local DNS lookup should be made to query for the CAS server address.

By default, the server is address is determined from the request. Aside from special headers, this option allows one to query DNS to look up the server address of the CAS server processing requests.

Type
Boolean
Default
false
Defined by
AuditEngineProperties

Required settings may be needed to activate or affect the feature; review them even when they have a default. Optional settings only need to be set to change a default or to turn on the behavior they control. Third party settings belong to libraries such as Spring Boot that CAS builds on; their own documentation may have more detail.

Notes on configuration

Configuration Metadata

The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.

Be Selective

This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.

YAGNI

Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.

Naming Convention

Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc.

:information_source: Note

When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value. The only possible exception to this rule is when naming actuator endpoints; The name of the actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.

Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.

Validation

Configuration properties are automatically validated on CAS startup to report issues with configuration binding, especially if defined CAS settings cannot be recognized or validated by the configuration schema. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.

Indexed Settings

CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.

Actuator Endpoints

The following endpoints are provided by CAS:

auditLog
CAS endpoint1 operationNot exposed by defaultcas-server-support-reports
auditevents
Third-party endpoint1 operationNot exposed by defaultcas-server-support-reports
1

Include the module that provides these endpoints in the WAR overlay:

Show in CAS Initializr Generate CAS Server WAR Overlay 


1
2
3
4
5



<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-reports</artifactId>
    <version>${cas.version}</version>
</dependency>





1



implementation "org.apereo.cas:cas-server-support-reports:${project.'cas.version'}"





1
2
3
4
5
6
7
8
9



dependencyManagement {
    imports {
        mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
    }
}

dependencies {
    implementation "org.apereo.cas:cas-server-support-reports"
}





1
2
3
4
5
6
7
8
9
10



dependencies {
    /*
        The following platform references are included automatically and are listed for reference only.

        implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
        implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
        
    */
    implementation "org.apereo.cas:cas-server-support-reports"
}
2

Turn the endpoints on and expose them over the web. One entry covers every operation. By default only info, health and status are exposed.



1
2
3



management.endpoint.auditLog.access=UNRESTRICTED
management.endpoint.auditevents.access=UNRESTRICTED
management.endpoints.web.exposure.include=auditLog,auditevents

Endpoints may be mapped to other paths. For example, to serve health at healthcheck:



1



management.endpoints.web.path-mapping.health=healthcheck

Storage

Audits can be managed via the following strategies.

Storage Description
File System See this guide.
JPA See this guide.
MongoDb See this guide.
Redis See this guide.
DynamoDb See this guide.
AWS Firehose See this guide.
REST See this guide.
Custom See this guide.

Audit Events

The following events are tracked and recorded in the audit log:

Name
MULTIFACTOR_AUTHENTICATION_BYPASS
AUTHENTICATION_EVENT
AUTHENTICATION
SERVICE_TICKET
PROXY_TICKET
TICKET_GRANTING_TICKET
PROXY_GRANTING_TICKET
SERVICE_TICKET_VALIDATE
PROTOCOL_SPECIFICATION_VALIDATE
REST_API_SERVICE_TICKET
REST_API_TICKET_GRANTING_TICKET
EVALUATE_RISKY_AUTHENTICATION
MITIGATE_RISKY_AUTHENTICATION
TRUSTED_AUTHENTICATION
SURROGATE_AUTHENTICATION_ELIGIBILITY_SELECTION
SURROGATE_AUTHENTICATION_ELIGIBILITY_VERIFICATION
SERVICE_ACCESS_ENFORCEMENT
SAVE_SERVICE
DELETE_SERVICE
DELEGATED_CLIENT
SAVE_CONSENT
VERIFY_CONSENT
SAML2_RESPONSE
SAML2_REQUEST
SAML2_METADATA_RESOLUTION
OIDC_CIBA_RESPONSE
OIDC_VERIFIABLE_CREDENTIAL_NOTIFICATION
OIDC_VERIFIABLE_CREDENTIAL_DEFERRED_ISSUANCE
OAUTH2_ACCESS_TOKEN_RESPONSE
OAUTH2_USER_PROFILE
OAUTH2_AUTHORIZATION_RESPONSE
OAUTH2_ACCESS_TOKEN_REQUEST
OIDC_ID_TOKEN
AUP_VERIFY
AUP_SUBMIT
CHANGE_PASSWORD
REQUEST_CHANGE_PASSWORD
REQUEST_FORGOT_USERNAME
ACCOUNT_REGISTRATION
LOGOUT