标签：des style http color io os ar java for
1. 架构
http://jasig.github.io/cas/4.0.0/planning/Architecture.html
The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.
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.
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:
Applications:
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.
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:
It is helpful to describe the CAS server in terms of three layered subsystems:
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.
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.
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.
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
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
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.
CAS user interface should properly and comfortably lend itself to all major browser vendors:
Note that certain older version of IE, particularly IE 9 and below may impose additional difficulty in getting the right UI configuration in place.
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
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"/>
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; }
}
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:
console.log()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.
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;
}
<form:form method="post" id="fm1" cssClass="fm-v clearfix"
commandName="${commandName}" htmlEscape="true"
onsubmit="return prepareSubmit(this);">
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.
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" %>
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.)
The CAS Web application includes a number of localized message files:
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
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.
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.
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.
/WEB-INF/classes folder, name it astheme_name.properties. Contents of this file should match the cas-theme-default.properties file.theme property.
标签：des style http color io os ar java for
原文地址：http://www.cnblogs.com/davidwang456/p/4022228.html
