See: Description
| Interface | Description |
|---|---|
| CasProtocolConstants |
Class that exposes relevant constants and parameters to
the CAS protocol.
|
| CasViewConstants |
Constants interface to host fields
related to view rendering and validation model.
|
| CentralAuthenticationService |
CAS viewed as a set of services to generate and validate Tickets.
|
| CipherExecutor<T,R> |
Responsible to define operation that deal with encryption, signing
and verification of a value.
|
| OidcConstants |
This is
OidcConstants. |
| TokenConstants |
This is
TokenConstants, an interface to hold constants relates to token authentication. |
| Class | Description |
|---|---|
| AbstractCentralAuthenticationService |
An abstract implementation of the
CentralAuthenticationService that provides access to
the needed scaffolding and services that are necessary to CAS, such as ticket registry, service registry, etc. |
| CentralAuthenticationServiceImpl |
Concrete implementation of a
CentralAuthenticationService, and also the
central, organizing component of CAS' internal implementation. |
| DefaultMessageDescriptor |
Simple parameterized message descriptor with a code that refers to a message bundle key and a default
message string to use if no message code can be resolved.
|
| MongoDbProperty |
This is
MongoDbProperty. |
| MongoDbPropertySource |
This is
MongoDbPropertySource. |
| MongoDbPropertySourceLocator |
This is
MongoDbPropertySourceLocator. |
| OidcCasClientRedirectActionBuilder |
This is
OidcCasClientRedirectActionBuilder. |
| OidcServerDiscoverySettings |
This is
OidcServerDiscoverySettings. |
This is the entry point to the part of the CAS processing that is independent of the user/program interface. This layer is mostly a service to create, manage, validate, query, and destroy tickets. The caller of this layer may be a Web application running in a Servlet container, but it may also be a Web Service client, RMI client, or even a program that finds these services compelling.
One first enters this layer with opaque Credentials requesting creation of a TGT. The Credentials are "opaque" because they are an object whose nature is irrelevant to CAS. The Credentials are carried through the layers until they can be presented to plugin configuration beans that may recognize the underlying type and process it. Simple Credentials might be an object with a userid and password, but they may also be an X.509 Certificate, Kerberos Ticket, Shibboleth artifact, XML SOAP header, or any other object.
The Credentials are presented to a set of objects plugged into the Authentication process by the system administrators. If one of these plugin elements recognizes the Credentials, validates their integrity, and maps them to the identity of a user in the local system, then CAS has logged someone on and creates a TGT.
The results of the login are somewhat opaque. The TGT references an Authentication object that references a Principal. Minimally the Principal contains a simple ID string. What else the Principal or Authentication object contain are transparent to CAS. These objects must be Serializable, because the Tickets and everything they reference may need to be checkpointed to disk or shared with multiple machines in a clustering configuration. CAS is managing the TGT and, as a result, it also saves everything in the concrete classes referenced by it.
Any additional information about the User fetched at login is of no direct interest to CAS. It may, however, be meaningful to the caller of this layer. In the case of an HTTP Servlet interface, this would be the View layer that generates, among other things, the response to the Ticket Validation query.
Having created a TGT, CAS then proceeds to create Service Tickets which are chained off the TGT, and in the case of Proxy authentication creates chains of TGTs for the Service Ticket. TGTs and STs are stored in a cache until they expire or are deleted. Various technologies can be plugged into the back end so that the Ticket cache is shared among machines or persisted across a reboot.