WORKERS AHEAD!

You are viewing the development documentation for the Apereo CAS server. The functionality presented here is not officially released yet. This is a work in progress and will be continually updated as development moves forward. You are most encouraged to test the changes presented.

Service HTTP Security Headers

CAS has ability to control, on a per-service basis, whether certain security-related HTTP headers should be injected into the response. While headers are typically enabled and defined globally as part of the CAS Security Filter, the strategy described here allows one to disable/enable the injection of these headers for certain applications and service requests and override the global defaults.

Global Configuration

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

_{The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.}

cas.http-web-request.cors.enabled=false

Whether CORS should be enabled for http requests.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

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.

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.enabled=...

This is the most common form of property configuration that is recognized by CAS, regardless of the actual property source, which might in fact be managed separately outside the CAS environment, by another system or cloud framework.

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.enabled="..." -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory. Note the placement of the system property which must be specified before the CAS web application is launched.

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.enabled=true

Allow CAS to inject and enforce http security headers via an http filter that are outlined here for caching, HSTS, etc.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.enabled=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      enabled: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.enabled="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_ENABLED="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.enabled="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

_{The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This
flag indicates that the presence of the setting
is not immediately necessary in the end-user CAS configuration, because a default value is assigned or
the activation of the feature is not conditionally controlled by the setting value. In other words, you should only include this field in your
configuration if you need to modify the default value or if you need to turn on the feature controlled by the setting.}

cas.http-web-request.allow-multi-value-parameters=false

Whether CAS should accept multi-valued parameters in incoming requests. Example block would to prevent requests where more than one service parameter is specified.

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.allow-multi-value-parameters=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    allow-multi-value-parameters: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.allow-multi-value-parameters="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_ALLOW_MULTI_VALUE_PARAMETERS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.allow-multi-value-parameters="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.characters-to-forbid=none

Characters to block in incoming requests. none is a special value. Separate characters by a space.

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.characters-to-forbid=none

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    characters-to-forbid: "none"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.characters-to-forbid="none" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CHARACTERS_TO_FORBID="none"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.characters-to-forbid="none"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.allow-credentials=true

The Access-Control-Allow-Credentials header Indicates whether or not the response to the request can be exposed when the credentials flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.allow-credentials=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      allow-credentials: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.allow-credentials="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ALLOW_CREDENTIALS="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.allow-credentials="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.allow-headers=

The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request. Default is everything.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.allow-headers=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      allow-headers: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.allow-headers="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ALLOW_HEADERS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.allow-headers="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.allow-methods=

The Access-Control-Allow-Methods header specifies the method or methods allowed when accessing the resource. This is used in response to a pre-flight request. The conditions under which a request is pre-flighted are discussed above. Default is everything.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.allow-methods=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      allow-methods: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.allow-methods="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ALLOW_METHODS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.allow-methods="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.allow-origin-patterns=

Comma-separated list of origin patterns to allow. Unlike allowed origins which only supports *, origin patterns are more flexible (for example https://*.example.com) and can be used when credentials are allowed. When no allowed origin patterns or allowed origins are set, CORS support is disabled.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.allow-origin-patterns=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      allow-origin-patterns: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.allow-origin-patterns="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ALLOW_ORIGIN_PATTERNS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.allow-origin-patterns="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.allow-origins=

The Origin header indicates the origin of the cross-site access request or preflight request. The origin is a URI indicating the server from which the request initiated. When credentials are allowed, '*' cannot be used and origin patterns should be configured instead. It does not include any path information, but only the server name.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.allow-origins=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      allow-origins: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.allow-origins="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_ALLOW_ORIGINS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.allow-origins="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.exposed-headers=

The Access-Control-Expose-Headers header lets a server accept headers that browsers are allowed to access.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.exposed-headers=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      exposed-headers: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.exposed-headers="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_EXPOSED_HEADERS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.exposed-headers="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.cors.max-age=3600

The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached.

org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.cors.max-age=3600

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    cors: 
      max-age: "3600"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.cors.max-age="3600" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CORS_MAX_AGE="3600"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.cors.max-age="3600"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.custom-headers=

Custom response headers to inject into the response as needed.

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.custom-headers=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    custom-headers: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.custom-headers="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_CUSTOM_HEADERS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.custom-headers="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.cache=true

When true, will inject the following headers into the response for non-static resources.

 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.cache=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      cache: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.cache="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_CACHE="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.cache="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.cache-control-static-resources=css|js|png|txt|jpg|ico|jpeg|bmp|gif

Files with these extensions are considered static, so they will be cached by browsers. The value is part of a RegEx.

This settings supports regular expression patterns. ^[?].

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.cache-control-static-resources=css|js|png|txt|jpg|ico|jpeg|bmp|gif

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      cache-control-static-resources: "css|js|png|txt|jpg|ico|jpeg|bmp|gif"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.cache-control-static-resources="css|js|png|txt|jpg|ico|jpeg|bmp|gif" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_CACHE_CONTROL_STATIC_RESOURCES="css|js|png|txt|jpg|ico|jpeg|bmp|gif"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.cache-control-static-resources="css|js|png|txt|jpg|ico|jpeg|bmp|gif"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.content-security-policy=script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';

Helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. Header value is made up of one or more directives. Multiple directives are separated with a semicolon. @nonce@ is a specific value which is replaced by a generated random value saved as the request attribute 'contentSecurityPolicyGeneratedNonce'.

This setting supports the Spring Expression Language.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.content-security-policy=script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      content-security-policy: "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.content-security-policy="script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_CONTENT_SECURITY_POLICY="script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.content-security-policy="script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.hsts=true

When true, will inject the following headers into the response: Strict-Transport-Security: ....

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.hsts=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      hsts: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.hsts="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_HSTS="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.hsts="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.hsts-options=max-age=15768000 ; includeSubDomains

Control the value of the Strict-Transport-Security header.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.hsts-options=max-age=15768000 ; includeSubDomains

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      hsts-options: "max-age=15768000 ; includeSubDomains"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.hsts-options="max-age=15768000 ; includeSubDomains" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_HSTS_OPTIONS="max-age=15768000 ; includeSubDomains"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.hsts-options="max-age=15768000 ; includeSubDomains"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.xcontent=true

When true, will inject the following headers into the response: X-Content-Type-Options: nosniff.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.xcontent=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      xcontent: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.xcontent="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_XCONTENT="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.xcontent="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.xframe=true

When true, will inject the following headers into the response: X-Frame-Options: DENY.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.xframe=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      xframe: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.xframe="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_XFRAME="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.xframe="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.xframe-options=DENY

Will inject values into the X-Frame-Options header into the response.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.xframe-options=DENY

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      xframe-options: "DENY"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.xframe-options="DENY" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_XFRAME_OPTIONS="DENY"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.xframe-options="DENY"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.xss=true

When true, will inject the following headers into the response: X-XSS-Protection: 1; mode=block.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.xss=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      xss: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.xss="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_XSS="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.xss="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.header.xss-options=1; mode=block

Will inject values into the X-XSS-Protection header into the response.

org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.header.xss-options=1; mode=block

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    header: 
      xss-options: "1; mode=block"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.header.xss-options="1; mode=block" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_HEADER_XSS_OPTIONS="1; mode=block"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.header.xss-options="1; mode=block"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.only-post-params=password

Parameters that are only allowed and accepted during posts.

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.only-post-params=password

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    only-post-params: "password"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.only-post-params="password" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_ONLY_POST_PARAMS="password"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.only-post-params="password"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.params-to-check=ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token

Parameters to sanitize and cross-check in incoming requests. Separate parameter names by a comma. The special value * instructs the Filter to check all parameters.

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.params-to-check=ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    params-to-check: "ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.params-to-check="ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_PARAMS_TO_CHECK="ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.params-to-check="ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.pattern-to-block=

Specify a regular expression that would be checked against the request URL. If a successful match is found, the request would be blocked.

This settings supports regular expression patterns. ^[?].

org.apereo.cas.configuration.model.core.web.security.HttpRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.pattern-to-block=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    pattern-to-block: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.pattern-to-block="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_PATTERN_TO_BLOCK="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.pattern-to-block="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.web.encoding=

Control and specify the encoding for all http requests.

org.apereo.cas.configuration.model.core.web.security.HttpWebRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.web.encoding=...

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    web: 
      encoding: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.web.encoding="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_WEB_ENCODING="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.web.encoding="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.http-web-request.web.force-encoding=true

Whether specified encoding should be forced for every request. Whether the specified encoding is supposed to override existing request and response encodings

org.apereo.cas.configuration.model.core.web.security.HttpWebRequestProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.http-web-request.web.force-encoding=true

CAS properties can be specified using the YAML syntax:

cas: 
  http-web-request: 
    web: 
      force-encoding: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.http-web-request.web.force-encoding="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_HTTP_WEB_REQUEST_WEB_FORCE_ENCODING="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.http-web-request.web.force-encoding="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

# Whether CAS should accept multi-valued parameters in incoming requests.
# cas.http-web-request.allow-multi-value-parameters=false

# Characters to block in incoming requests.
# cas.http-web-request.characters-to-forbid=none

# The Access-Control-Allow-Credentials header Indicates whether or not the response to the request can be exposed when the credentials flag is true.
# cas.http-web-request.cors.allow-credentials=true

# The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
# cas.http-web-request.cors.allow-headers=

# The Access-Control-Allow-Methods header specifies the method or methods allowed when accessing the resource.
# cas.http-web-request.cors.allow-methods=

# Comma-separated list of origin patterns to allow.
# cas.http-web-request.cors.allow-origin-patterns=

# The Origin header indicates the origin of the cross-site access request or preflight request.
# cas.http-web-request.cors.allow-origins=

# The Access-Control-Expose-Headers header lets a server accept headers that browsers are allowed to access.
# cas.http-web-request.cors.exposed-headers=

# The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached.
# cas.http-web-request.cors.max-age=3600

# Custom response headers to inject into the response as needed.
# cas.http-web-request.custom-headers=

# When true, will inject the following headers into the response for non-static resources.
# cas.http-web-request.header.cache=true

# Files with these extensions are considered static, so they will be cached by browsers.
# cas.http-web-request.header.cache-control-static-resources=css|js|png|txt|jpg|ico|jpeg|bmp|gif

# Helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.
# cas.http-web-request.header.content-security-policy=script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google.com; object-src 'none'; worker-src 'self' blob: 'unsafe-inline';

# When true, will inject the following headers into the response: {@code Strict-Transport-Security: ...}.
# cas.http-web-request.header.hsts=true

# Control the value of the {@code Strict-Transport-Security} header.
# cas.http-web-request.header.hsts-options=max-age=15768000 ; includeSubDomains

# When true, will inject the following headers into the response: {@code X-Content-Type-Options: nosniff}.
# cas.http-web-request.header.xcontent=true

# When true, will inject the following headers into the response: {@code X-Frame-Options: DENY}.
# cas.http-web-request.header.xframe=true

# Will inject values into the {@code X-Frame-Options} header into the response.
# cas.http-web-request.header.xframe-options=DENY

# When true, will inject the following headers into the response: {@code X-XSS-Protection: 1; mode=block}.
# cas.http-web-request.header.xss=true

# Will inject values into the {@code X-XSS-Protection} header into the response.
# cas.http-web-request.header.xss-options=1; mode=block

# Parameters that are only allowed and accepted during posts.
# cas.http-web-request.only-post-params=password

# Parameters to sanitize and cross-check in incoming requests.
# cas.http-web-request.params-to-check=ticket,service,renew,gateway,warn,method,target,SAMLart,pgtUrl,pgt,pgtId,pgtIou,targetService,entityId,token

# Specify a regular expression that would be checked against the request URL.
# cas.http-web-request.pattern-to-block=

# Control and specify the encoding for all http requests.
# cas.http-web-request.web.encoding=

# Whether specified encoding should be forced for every request.
# cas.http-web-request.web.force-encoding=true

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.

Note

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, specially 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.

Service HTTP Headers

The following properties are available and recognized by CAS for various modules and features:

Name	Default Value	Type	Group
`httpHeaderEnableCacheControl`	`true`	`BOOLEAN`	`HTTP_HEADERS`
`httpHeaderEnableXContentOptions`	`true`	`BOOLEAN`	`HTTP_HEADERS`
`httpHeaderEnableStrictTransportSecurity`	`true`	`BOOLEAN`	`HTTP_HEADERS`
`httpHeaderStrictTransportSecurity`		`STRING`	`HTTP_HEADERS`
`httpHeaderEnableXFrameOptions`	`true`	`BOOLEAN`	`HTTP_HEADERS`
`httpHeaderXFrameOptions`	`DENY`	`STRING`	`HTTP_HEADERS`
`httpHeaderEnableContentSecurityPolicy`	`true`	`STRING`	`HTTP_HEADERS`
`httpHeaderEnableXSSProtection`	`true`	`BOOLEAN`	`HTTP_HEADERS`

A sample JSON file follows:

{
  "@class" : "org.apereo.cas.services.CasRegisteredService",
  "serviceId" : "^https://.+",
  "name" : "sample service",
  "id" : 100,
  "properties" : {
    "@class" : "java.util.HashMap",
    "httpHeaderEnableXContentOptions" : {
      "@class" : "org.apereo.cas.services.DefaultRegisteredServiceProperty",
      "values" : [ "java.util.HashSet", [ "true" ] ]
    }
  }
}

CORS Policies

Cross-origin resource sharing (CORS) policies can also be defined per application in form of service properties.

The following properties are available and recognized by CAS for various modules and features:

Name	Default Value	Type	Group
`corsAllowCredentials`	`false`	`BOOLEAN`	`CORS`
`corsMaxAge`		`INTEGER`	`CORS`
`corsAllowedOrigins`		`STRING`	`CORS`
`corsAllowedOriginPatterns`		`STRING`	`CORS`
`corsAllowedMethods`		`STRING`	`CORS`
`corsAllowedHeaders`		`STRING`	`CORS`
`corsExposedHeaders`		`STRING`	`CORS`

A sample JSON file follows:

{
  "@class" : "org.apereo.cas.services.CasRegisteredService",
  "serviceId" : "^https://.+",
  "name" : "sample service",
  "id" : 100,
  "properties" : {
    "@class" : "java.util.HashMap",
    "corsMaxAge" : {
      "@class" : "org.apereo.cas.services.DefaultRegisteredServiceProperty",
      "values" : [ "java.util.HashSet", [ "1000" ] ]
    }
  }
}