1. 架构

http://jasig.github.io/cas/4.0.0/planning/Architecture.html

System Components

The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.

CAS Server

The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.

CAS Clients

The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.

Platforms:

• Apache httpd Server (mod_auth_cas module)
• Java (Java CAS Client)
• .NET (.NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)
• Ruby (rubycas-client)

Applications:

• Outlook Web Application (ClearPass + .NET CAS Client)
• Atlassian Confluence
• Atlassian JIRA
• Drupal
• Liferay
• uPortal

When the term “CAS client” appears in this manual without further qualification, it refers to the integration components such as the Jasig Java CAS Client rather than to the application relying upon (a client of) the CAS server.

Protocols

Clients communicate with the server by any of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.

Supported protocols:

• CAS (versions 1, 2, and 3)
• SAML 1.1
• OpenID
• OAuth (1.0, 2.0)

Software Components

It is helpful to describe the CAS server in terms of three layered subsystems:

• Web (Spring MVC/Spring Webflow)
• Ticketing
• Authentication

Almost all deployment considerations and component configuration involve those three subsystems. The Web tier is the endpoint for communication with all external systems including CAS clients. The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access. The SSO session begins with the issuance of a ticket-granting ticket on successful authentication, thus the ticketing subsystem frequently delegates to the authentication subsystem.

The authentication system is typically only processing requests at the start of the SSO session, though there are other cases when it can be invoked (e.g. forced authentication).

2. 协议

http://jasig.github.io/cas/4.0.0/protocol/CAS-Protocol.html

The CAS protocol is a simple and powerful ticket-based protocol developed exclusively for CAS. A complete protocol specification may be found at http://www.jasig.org/cas/protocol.

It involves one or many clients and one server.
Clients are embedded in cassified applications (called “CAS services”) whereas the CAS server is a standalone component: - the CAS server is responsible for authenticating users and granting accesses to applications - the CAS clients protect the CAS applications and retrieve the identity of the granted users from the CAS server.

The key concepts are: - the TGT (Ticket Granting Ticket), stored in the CASTGC cookie, represents a SSO session for a user - the ST (Service Ticket), transmitted as a GET parameter in urls, stands for the access granted by the CAS server to the cassified application for a specific user.

Versions

The current CAS protocol is the version 3.0, implemented by the CAS server 4.0.
It’s mainly a capture of the most common enhancements built on top of the CAS protocol revision 2.0.
Among all features, the most noticable update between versions 2.0 and 3.0 is the ability to return the authentication/user attributes in the /serviceValidate response.

Web flow diagram

Proxy web flow diagram

One of the most powerful feature of the CAS protocol is the ability for a CAS service to act as a proxy for another CAS service, transmitting the user identity.

Other protocols

Even if the primary goal of the CAS server is to implement the CAS protocol, other protocols are also supported as extensions: - OpenID - OAuth - SAML

Delegated Authentication

Using the CAS protocol, the CAS server can also be configured to delegate the authentication to another CAS server.

3. 界面

http://jasig.github.io/cas/4.0.0/installation/User-Interface-Customization.html

Overview

Branding the CAS User Interface (UI) involves simply editing the CSS stylesheet and also a small collection of relatively simple JSP include files, also known as views. Optionally, you may also wish to modify the text displayed and/or add additional Javascript effects on these views.

All the files that we’ll be discussing in this section that concern the theme are located in and referenced from: /cas-server-webapp/src/main/webapp.

Browser Support

CAS user interface should properly and comfortably lend itself to all major browser vendors:

• Google Chrome
• Mozilla Firefox
• Apple Safari
• Microsoft Internet Explorer

Note that certain older version of IE, particularly IE 9 and below may impose additional difficulty in getting the right UI configuration in place.

Getting Started

CSS

The default styles are all contained in a single file located in css/cas.css. This location is set in WEB-INF/classes/cas-theme-default.properties. If you would like to create your own css/custom.css file, for example, you will need to update standard.custom.css.file key in that file.

standard.custom.css.file=/css/cas.css
cas.javascript.file=/js/cas.js

CSS per Locale

Selecting CSS files per enabled locale would involve changing the top.jsp file to include the below sample code:

<%
    String cssFileName = "cas.css"; // default
    Locale locale = request.getLocale();
 
    if (locale != null && locale.getLanguage() != null){
       String languageCssFileName = "cas_" + locale.getLanguage() + ".css";
       cssFileName = languageCssFileName; //ensure this file exists
    }
 
%>
<link href="/path/to/css/<%=cssFileName%>" rel="stylesheet" type="text/css"/>

Responsive Design

CSS media queries bring responsive design features to CAS which would allow adopter to focus on one theme for all appropriate devices and platforms. These queries are defined in the same css/cas.css file. Below follows an example:

@media only screen and (max-width: 960px) { 
  footer { padding-left: 10px; }
}

@media only screen and (max-width: 799px) { 
  header h1 { font-size: 1em; }
  #login { float: none; width: 100%; }
  #fm1 .row input[type=text], 
  #fm1 .row input[type=password] { width: 100%; padding: 10px; box-sizing: border-box; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; }
  #fm1 .row .btn-submit { outline: none; -webkit-appearance: none; -webkit-border-radius: 0; border: 0; background: #210F7A; color: white; font-weight: bold; width: 100%; padding: 10px 20px; -webkit-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; }
  #fm1 .row .btn-reset { display: none; }
  #sidebar { margin-top: 20px; }
  #sidebar .sidebar-content { padding: 0; }
}

Javascript

If you need to add some JavaScript, feel free to append js/cas.js.

You can also create your own custom.js file, for example, and call it from within WEB-INF/view/jsp/default/ui/includes/bottom.jsp like so:

<script type="text/javascript" src="<c:url value="/js/custom.js" />"></script> 

If you are developing themes per service, each theme also has the ability to specify a custom cas.js file under thecas.javascript.file setting.

The following Javascript libraries are utilized by CAS automatically:

• JQuery
• JQuery UI
• JavaScript Debug: A simple wrapper for console.log()

Preserving Anchor Fragments

Anchors/fragments may be lost across redirects as the server-side handler of the form post ignores the client-side anchor, unless appended to the form POST url. This is needed if you want a CAS-authenticated application to be able to use anchors/fragments when bookmarking.

Changes to cas.js

/**
 * Prepares the login form for submission by appending any URI
 * fragment (hash) to the form action in order to propagate it
 * through the re-direct (i.e. store it client side).
 * @param form The login form object.
 * @returns true to allow the form to be submitted.
 */
function prepareSubmit(form) {
    // Extract the fragment from the browser‘s current location.
    var hash = decodeURIComponent(self.document.location.hash);
 
    // The fragment value may not contain a leading # symbol
    if (hash && hash.indexOf("#") === -1) {
        hash = "#" + hash;
    }
   
    // Append the fragment to the current action so that it persists to the redirected URL.
    form.action = form.action + hash;
    return true;
}

Changes to Login Form

<form:form method="post" id="fm1" cssClass="fm-v clearfix" 
        commandName="${commandName}" htmlEscape="true" 
        onsubmit="return prepareSubmit(this);">

JSP

The default views are found at WEB-INF/view/jsp/default/ui/.

Notice top.jsp and bottom.jsp include files located in the ../includes directory. These serve as the layout template for the other JSP files, which get injected in between during compilation to create a complete HTML page.

The location of these JSP files are configured in WEB-INF/classes/default_views.properties.

Tag Libraries

The following JSP tag libraries are used by the user interface:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

Glossary of Views

• casAccountDisabledView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that is disabled in the underlying account store (i.e. LDAP)

• casAccountLockedView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that is locked in the underlying account store (i.e. LDAP)

• casBadHoursView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that is not allowed authentication within the current time window in the underlying account store (i.e. LDAP)

• casBadWorkstationView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that is not allowed authentication from the current workstation in the underlying account store (i.e. LDAP)

• casExpiredPassView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that has expired in the underlying account store (i.e. LDAP)

• casMustChangePassView
  Specific to Password Policy Enforcement; displayed in the event that authentication encounters an account that must change its password in the underlying account store (i.e. LDAP)

• casWarnPassView
  Specific to Password Policy Enforcement; displayed when the user account is near expiration based on specified configuration (i.e. LDAP)

• authorizationFailure
  Displayed when a user successfully authenticates to the services management web-based administrative UI included with CAS, but the user is not authorized to access that application.

• casConfirmView
  Displayed when the user is warned before being redirected to the service. This allows users to be made aware whenever an application uses CAS to log them in. (If they don’t elect the warning, they may not see any CAS screen when accessing an application that successfully relies upon an existing CAS single sign-on session.) Some CAS adopters remove the ‘warn’ checkbox in the CAS login view and don’t offer this interstitial advisement that single sign-on is happening.

• casGenericSuccess
  Displayed when the user has been logged in without providing a service to be redirected to.

• casLoginView
  Main login form.

• casLogoutView
  Displayed when the user logs out.

• errors Displayed when CAS experiences an error it doesn’t know how to handle (an unhandled Exception). For instance, CAS might be unable to access a database backing the services registry. This is the generic CAS error page. It’s important to brand it to provide an acceptable error experience to your users.

• serviceErrorView
  Used in conjunction with the service registry feature, displayed when the service the user is trying to access is not allowed to use CAS. The default in-memory services registry configuration, in ‘deployerConfigContext.xml’, allows all users to obtain a service ticket to access all services.

• serviceErrorSsoView 
  Displayed when a user would otherwise have experienced noninteractive single sign-on to a service that is, per services registry configuration, disabled from participating in single sign-on. (In the default services registry registrations, all services are permitted to participate in single sign-on, so this view will not be displayed.)

Localization

The CAS Web application includes a number of localized message files:

• English (US)
• Spanish
• French
• Russian
• Netherlands (Nederlands)
• Swedish (Svenskt)
• Italian (Italiano)
• Urdu
• Chinese (Simplified)
• Dutch (Deutsch)
• Japanese
• Croatian
• Czech
• Slovenian
• Polish
• Portuguese (Brazil)
• Turkish
• Farsi
• Arabic

In order to “invoke” a specific language for the UI, the /login endpoint may be passed a locale parameter as such:

https://cas.server.edu/login?locale=it

Configuration

All message bundles are marked under messages_xx.properties files at WEB-INF/classes. The default language bundle is for the English language and is thus called messages.properties. If there any custom messages that need to be presented into views, they may also be formatted under custom_messages_xx.properties files.

Messages are parsed and loaded via the following configuration:

<bean id="messageSource" class="org.jasig.cas.web.view.CasReloadableMessageBundle"
          p:basenames-ref="basenames" p:fallbackToSystemLocale="false" p:defaultEncoding="UTF-8"
          p:cacheSeconds="180" p:useCodeAsDefaultMessage="true" />
    
<util:list id="basenames">
    <value>classpath:custom_messages</value>
    <value>classpath:messages</value>
</util:list>

Messages are then read on each JSP view via the following sample configuration:

<spring:message code="message.key" />

In the event that the code is not found in the activated resource bundle, the code itself will be used verbatim.

Themes

With the introduction of Service Management application, deployers are now able to switch the themes based on different services. For example, you may want to have different login screens (different styles) for staff applications and student applications. Or, you want to show two layouts for day time and night time. This document could help you go through the basic settings to achieve this.

Components

Configuration of service-specific themes is backed by the Spring framework and provided by the following component:

<bean id="themeResolver" class="org.jasig.cas.services.web.ServiceThemeResolver"
    p:defaultThemeName="${cas.themeResolver.defaultThemeName}"
    p:servicesManager-ref="servicesManager"
    p:argumentExtractors-ref="argumentExtractors" />

Furthermore, deployers may be able to use the functionality provided by the ThemeChangeInterceptor of Spring framework to provide theme configuration per each request.

Configuration

• Add another theme properties file, which must be placed to the root of /WEB-INF/classes folder, name it astheme_name.properties. Contents of this file should match the cas-theme-default.properties file.
• Add the location of related styling files, such as CSS and Javascript in the file above.
• Specify the name of your theme for the service definition under the theme property.