The CAS service management facility allows CAS server administrators to declare and configure which services
(CAS clients) may make use of CAS in which ways. The core component of the service management facility is the
service registry, provided by the
ServiceRegistryDao component, that stores one or more registered services
containing metadata that drives a number of CAS behaviors:
- Authorized services - Control which services may participate in a CAS SSO session.
- Forced authentication - Provides administrative control for forced authentication.
- Attribute release - Provide user details to services for authorization and personalization.
- Proxy control - Further restrict authorized services by granting/denying proxy authentication capability.
- Theme control - Define alternate CAS themes to be used for particular services.
The service management webapp is a Web application that may be deployed along side CAS that provides a GUI to manage service registry data.
The Service Management web application is available for demo at https://jasigcasmgmt.herokuapp.com/cas-management
It is not required to use the service management facility explicitly. CAS ships with a default configuration that is
suitable for deployments that do not need or want to leverage the capabilities above. The default configuration allows
any service contacting CAS over https/imaps to use CAS and receive any attribute configured by an
A premier consideration around service management is whether to leverage the user interface. If the service management
webapp is used, then a
ServiceRegistryDao that provides durable storage (e.g.
JpaServiceRegistryDaoImpl) must be
used to preserve state across restarts.
It is perfectly acceptable to avoid the service management webapp Web application for managing registered service data. In fact, configuration-driven methods (e.g. XML, JSON) may be preferable in environments where strict configuration management controls are required.
Registered services present the following metadata:
||Required unique identifier. In most cases this is managed automatically by the
||Required name (255 characters or less). Must include valid characters allowed by the file system.|
||Optional free-text description of the service. (255 characters or less)|
||Optional path to an image file that is the logo for this service. The image will be displayed on the login page along with the service description and name.|
||Required Ant pattern or regular expression describing a logical service. A logical service defines one or more URLs where a service or services are located. The definition of the url pattern must be done carefully because it can open security breaches. For example, using Ant pattern, if you define the following service :
||Optional Spring theme that may be used to customize the CAS UI when the service requests a ticket. See this guide for more details.|
||Determines whether the service is able to proxy authentication, not whether the service accepts proxy authentication.|
||Required value that determines relative order of evaluation of registered services. This flag is particularly important in cases where two service URL expressions cover the same services; evaluation order determines which registration is evaluated first.|
||Set of authentication handler names that must successfully authenticate credentials in order to access the service.|
||The policy that describes the set of attributes allows to be released to the application, as well as any other filtering logic needed to weed some out. See this guide for more details on attribute release and filters.|
||Defines how this service should be treated once the logout protocol is initiated. Acceptable values are
||The provider configuration which dictates what value as the “username” should be sent back to the application. See this guide for more details on attribute release and filters.|
||The strategy configuration that outlines and access rules for this service. It describes whether the service is allowed, authorized to participate in SSO, or can be granted access from the CAS perspective based on a particular attribute-defined role, aka RBAC. See this guide for more details on attribute release and filters.|
||The public key associated with this service that is used to authorize the request by encrypting certain elements and attributes in the CAS validation protocol response, such as the PGT or the credential. See this guide for more details on attribute release and filters.|
||URL endpoint for this service to receive logout requests. See this guide for more details|
||Extra metadata associated with this service in form of key/value pairs. This is used to inject custom fields into the service definition, to be used later by extension modules to define additional behavior on a per-service basis.|
Configure Service Access Strategy
See this guide for more info please.
Configure Service Custom Properties
See this guide for more info please.
Configure Proxy Authentication Policy
Each registered application in the registry may be assigned a proxy policy to determine whether the service is allowed for proxy authentication. This means that a PGT will not be issued to a service unless the proxy policy is configured to allow it. Additionally, the policy could also define which endpoint urls are in fact allowed to receive the PGT.
Note that by default, the proxy authentication is disallowed for all applications.
Disallows proxy authentication for a service. This is default policy and need not be configured explicitly.
A proxy policy that only allows proxying to PGT urls that match the specified regex pattern.
Persisting Registered Service Data
This DAO is an in-memory services management seeded from registration beans wired via Spring beans.
This component is NOT suitable for use with the service management webapp since it does not persist data. On the other hand, it is perfectly acceptable for deployments where the XML configuration is authoritative for service registry data and the UI will not be used.
This DAO reads services definitions from JSON configuration files at the application context initialization time. JSON files are expected to be found inside a configured directory location and this DAO will recursively look through the directory structure to find relevant JSON files.
A sample JSON file follows:
You MUST consider that if your CAS server deployment is clustered, each CAS node in the cluster must have access to the same set of JSON configuration files as the other, or you may have to devise a strategy to keep changes synchronized from one node to the next.
The JSON service registry is also able to auto detect changes to the specified directory. It will monitor changes to recognize file additions, removals and updates and will auto-refresh CAS so changes do happen instantly.
Please make sure all field values in the JSON blob are correctly escaped, specially for the service id. If the service is defined as a regular expression, certain regex constructs such as "." and "\d" need to be doubly escaped.
The naming convention for new JSON files is recommended to be the following:
Based on the above formula, for example the above JSON snippet shall be named:
As you add more files to the directory, you need to be absolutely sure that no two service definitions will have the same id. If this happens, loading one definition will stop loading the other. While service ids can be chosen arbitrarily, make sure all service numeric identifiers are unique. CAS will also output warnings if duplicate data is found.
This DAO uses a MongoDb instance to load and persist service definitions. Support is enabled by adding the following module into the Maven overlay:
This implementation auto-configures most of the internal details.
The following configuration in
cas.properties is required.
Service registry implementation which stores the services in a LDAP Directory. Uses an instance of
LdapRegisteredServiceMapper, that by default is
DefaultLdapRegisteredServiceMapper in order to configure settings for retrieval, search and persistence of service definitions. By default, entries are assigned the
casRegisteredService attribute and are looked up by the
Note that the configuration of the mapper is optional and need not explicitly exist.
The default mapper has support for the following optional items:
Service definitions are by default stored inside the
serviceDefinitionAttribute attribute as JSON objects. The format and syntax of the JSON is identical to that of
Stores registered service data in a database; the preferred choice when using the service management webapp. The following schema shall be generated by CAS automatically for brand new deployments, and must be massaged when doing CAS upgrades:
The following configuration template may be applied to
deployerConfigContext.xml to provide for persistent
registered service storage.
You will also need to change the property
hibernate.dialect in adequacy with your database in
For example, for MYSQL the setting would be:
You will also need to ensure that the xml configuration file contains the
Finally, be sure to add those to your
Service Management Webapp
The Services Management web application is a standalone application that helps one manage service registrations and entries via a customizable user interface. The management web application MUST share the same registry configuration as the CAS server itself so the entire system can load the same services data. To learn more about the management webapp, please see this guide.