CAS – Central Authentication Service


CAS URIs and Tickets

CAS achieves Single sign-on features through URIs and by generating different tickets. Refer the table below for the list of URIs CAS uses.

URI Description
/login

It responds to credentials by acting as a credential acceptor and otherwise acts as a credential requestor

/logout

It destroys a client's single sign-on CAS session

/validate

Checks the validity of a service ticket. It does not handle proxy authentication

/serviceValidate

Checks the validity of a service ticket and returns an XML-fragment response and also generate and issue proxy-granting tickets when requested

/proxyValidate

Performs the same validation tasks as /serviceValidate and additionally validate proxy tickets.

/proxy

Provides proxy tickets to services that have acquired proxy-granting tickets and will be proxying authentication to back-end services.

/samlValidate

 

/services/add.html

An admin functionality. Adds services to Registered Services list.

/services/edit.html

An admin functionality. Edits the registered services

/services/manage.html

Provides a screen to manage registered services (add/edit/delete services)

/services/logout.html

Logs out the admin from services page

/services/loggedOut.html

Logs out the admin from services page

/services/deleteRegisteredService.html

Deletes the service given in "id" parameter

/openid/*

Maps requests for usernames to a page that displays the Login URL for an OpenId Identity Provider


The above URIs generates different types of tickets. So before discussing the above URIs, lets us see an overview of different tickets generated by CAS.

Ticket in CAS is nothing but a random string with a prefix (for identifying what type of ticket it is Ex: ST - service ticket) which acts as a unique identifier for an operation.


Types of tickets generated by CAS:

 

Ticket-granting ticket (TGT):

Ticket granting ticket will be generated when the /login url is passed to CAS server and the credentials provided are successfully authenticated. A TGT is the main access into the CAS service layer. Without a TGT, a user of CAS cannot do anything. TGT is a random string with a prefix “TGT-“. TGT will be added to an HTTP cookie upon the establishment of single sign-on and whenever user access different applications, this cookie will be referred for auto-logging in the user.

Ticket Granting Cookie: Ticket-granting cookie is an HTTP cookie set by CAS upon the establishment of a single sign-on session. This cookie maintains login state for the client and when client navigates to different applications, this cookie will be checked to auto-login the user. Ticket-granting cookies will be destroyed when the client closes the browser. They also can be destroyed when the clients clicks on Logout link. The value of ticket-granting cookies SHOULD begin with the characters, "TGC-".

Service Ticket (ST):

The service ticket (ST) will be generated when the CAS url contains service parameter and the credentials passed are successfully authenticated.

Ex: https://server/cas/login?service=http%3A%2F%2Fwww.service.com

The service you pass through url should be a registered service registered through services manager of CAS else an unauthorized service exception will be thrown.

Service ticket is a random string that is used by client as a credential to obtain access to a service. Service ticket must begin with “ST-“.

Ex: ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

When generating service ticket, service identifier (usually service url) should not be part of service ticket.



Proxy Ticket (PT):

Brief description about proxy: A proxy is something that acts as a server, but when given requests from clients, acts itself as a client to the real servers. An HTTP proxy doesn't forward every request sent through it. Instead, it first examines if it already has the requested web page in its cache. If so, then it returns that page without sending another request to the destination server. Because proxies completely terminate the communication channel, they are considered a more secure firewall technology than packet filters, because they dramatically increase the isolation between the networks.

In CAS, proxy is a service that wants to access other services on behalf of a particular user. Proxy tickets (PT) are generated from CAS upon a services’ presentation of a valid Proxy granting Ticket (PGT), and a service identifier (the value of parameter “service” of the /proxy url) for the back-end service to which it is connecting. PT is a random string that a service uses as a credential to obtain access to a back-end service on behalf of a client.

Proxy tickets are only valid for the service identifier specified to /proxy url when they were generated. Proxy tickets should begin with the characters, “PT-“.

Proxy-granting Ticket (PGT):

Proxy-granting tickets are obtained from CAS upon validation of a service ticket or a proxy ticket. If a service wishes to proxy a client's authentication to a back-end service, it must acquire a proxy-granting ticket. Acquisition of this ticket is handled through a proxy callback URL. This URL will uniquely and securely identify the back-end service that is proxying the client's authentication. The back-end service can then decide whether or not to accept the credentials based on the back-end service's identifying callback URL.

Proxy callback: The proxy callback mechanism works as follows:

1. The service that is requesting a proxy-granting ticket specifies upon initial service ticket or proxy ticket validation the HTTP request parameter "pgtUrl" to /serviceValidate (or /proxyValidate). This is a callback URL of the service to which CAS will connect to verify the service's identity. This URL must be HTTPS, and CAS must verify both that the SSL certificate is valid and that its name matches that of the service. If the certificate fails validation, no proxy-granting ticket will be issued, and the CAS service response must not contain a <proxyGrantingTicket> block.

On ticket validation success:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>username</cas:user>
<cas:proxyGrantingTicket>PGTIOU-84678-8a9d...
</cas:proxyGrantingTicket>
</cas:authenticationSuccess>
</cas:serviceResponse>

On ticket validation failure:
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code="INVALID_TICKET">
Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized </cas:authenticationFailure>
</cas:serviceResponse>

At this point, the issuance of a proxy-granting ticket is halted, but service ticket validation will continue, returning success or failure as appropriate. If certificate validation is successful, issuance of a proxy-granting ticket proceeds as in step 2.

2. CAS uses an HTTP GET request to pass the HTTP request parameters "pgtId" and "pgtIou" to the pgtUrl.

3. If the HTTP GET returns an HTTP status code of 200 (OK), CAS must respond to the /serviceValidate (or /proxyValidate) request with a service response containing the proxy-granting ticket IOU within the <cas:proxyGrantingTicket> block. If the HTTP GET returns any other status code, excepting HTTP 3xx redirects, CAS must respond to the /serviceValidate (or /proxyValidate) request with a service response that must not contain a <cas:proxyGrantingTicket> block. CAS may follow any HTTP redirects issued by the pgtUrl. However, the identifying callback URL provided upon validation in the <proxy> block must be the same URL that was initially passed to /serviceValidate (or /proxyValidate) as the "pgtUrl" parameter.

4. The service, having received a proxy-granting ticket IOU in the CAS response, and both a proxy-granting ticket and a proxy-granting ticket IOU from the proxy callback, will use the proxy-granting ticket IOU to correlate the proxy-granting ticket with the validation response. The service will then use the proxy-granting ticket for the acquisition of proxy tickets as described in “Proxy Tickets” Section.

A proxy-granting ticket is a random string that is used by a service to obtain proxy tickets for obtaining access to a back-end service on behalf of a client. PGT may be used by services to obtain multiple proxy tickets. PGTs are not one time use tickets. Proxy-granting tickets must expire when the client whose authentication is being proxied logs out of CAS.

Proxy-granting tickets should begin with the characters "PGT-".

Proxy-Granting Ticket IOU (PGTIOU):

A proxy-granting ticket IOU is a random string with prefix "PGTIOU-" that is placed in the response provided by /serviceValidate and /proxyValidate used to correlate a service ticket or proxy ticket validation with a particular proxy-granting ticket. Full description of this process is available at Proxy-granting ticket section.

Let me put this process in simple words and the full description is given in Proxy-granting ticket section.

A request is sent for a PGT through /serviceValidate or /proxyValidate URI. CAS server can't give PGT back in its response, because its not convinced of the requestor identity. If the requestor identity is the correct identity, then CAS says "IOU (I Owe You) a PGT" and sends PGTIOU. The requestor, having received a PGTIOU in the CAS response, and both a PGT and a PGTIOU from the proxy callback which was given as value of pgturl parameter when request is sent, will use the proxy-granting ticket IOU to correlate the proxy-granting ticket with the validation response. The requestor will then use the proxy-granting ticket for the acquisition of proxy tickets, if the requestor is the correct identity.

Ticket granting ticket IOU (TGTIOU):

On a ticket validation, a service can request a proxy ticket. In CAS 2, the way we authenticate this requesting service is to send the PGT, PGTIOU pair to a proxy callback URL specified as a request parameter. This proxy callback URL must be over a secure channel. We verify its certificate. The ability to receive this callback authenticates the receiver. We then return in the ticket validation response the TGTIOU. From the response, the service extracts the TGTIOU and uses it to lookup the TGT from where it cached it. (IOU is a short form of I Owe You).

Login Ticket (LT):

A login ticket is a string that is generated by /login as a credential requestor and passed to /login as a credential acceptor for username/password authentication. Its purpose is to prevent the replaying of credentials due to bugs in web browsers. Login tickets issued by /login must be unique and should begin with the characters, "LT-".

 

All CAS tickets and the value of ticket granting cookie must contain adequate secure random data so that a ticket is not guessable in a reasonable period of time through brute-force attacks and also must contain only characters from the set {A-Z, a-z, 0-9, and the special characters ?-'}. Ticket-granting ticket, service tickets, proxy tickets and login tickets must only be valid for one authentication attempt. Whether or not authentication was successful, CAS must then invalidate these tickets, causing all future authentication attempts with that instance of that particular ticket to fail. CAS should expire invalidated service tickets in a reasonable period of time (max 5 minutes) after they are issued. If a service presents for validation an expired service ticket, CAS must respond with a validation failure response.

 

Description of URIs

/logout:

/logout destroys the single sign-on session and the ticket-granting cookie. Any subsequent requests to /login will display the login form requesting the credentials from user (except trusted authentication). /logout will display a page stating that user has logged out.

"url" parameter can be specified to /logout and if specified, url will be displayed in the logout page along with the logout message. After client clicks on the url link in logout page, he will be redirected to the specified url. If client want to change the behaviour, he can edit "casLogoutView.jsp" page located in the \cas-server-webapp\src\main\webapp\WEB-INF\view\jsp\default\ui directory. For ex., instead of displaying the url link in the logout page, if client wants to be redirected to the specified url, he can comment out lines "<p><spring:message code="screen.logout.redirect" arguments="${fn:escapeXml(param.url)}" /> </p>" and add a scriptlet "<% response.sendRedirect(request.getParameter("url")); %>".


/validate:

/validate checks the validity of the service. CAS validates the service ticket with the service ticket generated from credentials that are obtained from request and if failed, will display failure response. On success, /validate will return username (principal) with the response. /validate is part of the CAS 1.0 protocol and thus does not handle proxy authentication. CAS will respond with a ticket validation failure response when a proxy ticket is passed to /validate.

Following parameters may be specified to /validate URI.
• service (required) – the identifier (usually url) of the service.
• ticket (required) – the service ticket issued by /login.
• renew (option) – if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials (from login form or trusted authentication where single sign-on session will be created). It will fail if the ticket was issued from a single sign-on session.

/serviceValidate:

/serviceValidate checks the validity of service ticket and returns response. It does the same job as /validate and also should generate proxy-granting tickets if needed. /serviceValidate will not return a successful authentication if it receives a proxy ticket. If /serviceValidate receives a proxy ticket, the error message is sent in response. CAS also verifies the service identifier with the registered services and if no registered service is matching with the given service identifier, an error response will be sent back. /serviceValidate is an extension of /validate in CAS 2.0.

/serviceValidate will only validate service tickets (tickets with zero entries in the proxy chain).

Following parameters may be specified to /validate URI.
• service (required) – the identifier (usually url) of the service.
• ticket (required) – the service ticket issued by /login.
• renew (option) – if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials (from login form or trusted authentication where single sign-on session will be created). It will fail if the ticket was issued from a single sign-on session.
• pgturl – the url of proxy callback. If a service wishes to proxy a client's authentication to a back-end service, it must acquire a proxy-granting ticket. Acquisition of this ticket is handled through a proxy callback URL. This URL will uniquely and securely identify the back-end service that is proxying the client's authentication. The back-end service can then decide whether or not to accept the credentials based on the back-end service's identifying callback URL. Proxy callback mechanism is explained in Proxy-granting ticket section.

/serviceValidate will return an xml-formatted response. On success, the response contains the username (principal) and the proxy-granting ticket. On failure, the response contains the error code with the respective failure message.

Following are the error codes returned by /serviceValidate response if /serviceValidate fails.
INVALID_REQUEST - not all of the required request parameters were present
INVALID_TICKET - the ticket provided was not valid, or the ticket did not come from an initial login and "renew" was set on validation.
INVALID_SERVICE - the ticket provided was valid, but the service specified did not match the service associated with the ticket.
INTERNAL_ERROR - an internal error occurred during ticket validation

/proxyValidate:

/proxyValidate does the same job as /serviceValidate except it validates proxy tickets apart from service tickets. The parameters and error codes are also similar. The success response contains PGT and the list of proxys through which the authentication has proceeded. Most recently visited proxy will be on the top and least recently visited one on the bottom.

/proxy:

/proxy provides proxy tickets to the services that have acquired PGT through /proxyValidate or /serviceValidate.

Following parameters are required for /proxy URI.
• pgt – proxy-granting ticket
• targetService – the service identifier (need not be service url only) of the back-end service. This service identifier must match the service identifier specified to /proxyValidate upon validation of proxy ticket.

/proxy will return an xml-formatted service response. Success response should contain proxy ticket and failure response should contain the error code with appropriate message. The error codes that will be returned in /proxy response are INVALID_REQUEST, BAD_PGT, INTERNAL_ERROR. BAD_PGT means "the pgt provided is invalid".


/samlValidate:

The SAML (Security Assertion Markup Language) framework is a standard ratified by OASIS that facilitates the exchange of authentication and authorisation information across disparate systems. This means service providers (the owners of web-based resources) can query identity providers (the owners of data about users) for information about their users and grant access based on that information. The framework consists of an XML language that defines the structure of messages that are exchanged by systems to share user data. The framework also defines rules about the content of these messages and how they should be exchanged. For example, if you want to get the information of google users (google accounts), we need to use SAML.

/samlValidate is same as /sericeValidate except that it sends request or receives response conforming to SAML XSD schema.

/services/add.html:

/services/add.html adds services to ServiceRegistry. This displays the admin form where an admin can register the services to redirect the client to a specific service identifier after successful login.

/services/edit.html:

/services/edit.html edits the details of services in registry. This displays the admin form where an admin can edit/update the registered services. "id" parameter can be specified and based on the value of the "id" parameter, the respective fields will be prefilled with the registered service details. If no "id" parameter is specified, this URI will act as /services/add.html.

/services/deleteRegisteredService.html:

/services/deleteRegisteredService.html deletes the service given in the "id" parameter. Parameter "id" is required and should contain the service id.

/services/manage.html:

/services/manage.html displays the list of all registered services and provides and option to edit or delete the registered services. This also provides an option to the client to add new service to the registry. Basically this URI manages the registered services.

/services/loggedOut.html or /services/logout.html:

/services/loggedOut.html logs out the client from /services.

/openId/*:

OpenID is a shared identity service, which allows Internet users to log on to many different web sites using a single digital identity, single sign-on, eliminating the need for a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide.

An OpenID is in the form of a URL. This URL can be the domain name of your own website, or the URL of an OpenID identity provider. When you log in with an OpenID, you have to log in to the identity provider for validation.

CAS supports openId. CAS maps requests for usernames to a page that displays the Login URL for an OpenId Identity Provider.

<<Previous page Next page>>


blog comments powered by Disqus