Http://www.blogjava.net/rain1102/articles/227739.html
CAs (central authentication Service) is an open source project initiated by Yale University, and according to statistics, about 10 Java projects that use open source to build Web SSO, there are 8 of them using CAS. I disagree with these statistics, but one thing is certain that CAS is the most straightforward and secure SSO option I think.
This section focuses on the security of CAs and why CAs are designed with a little bit of cryptography in the basics, and I hope to help readers understand the CAS protocol in a deeper way. From the structural system, CAS consists of two parts:l CAS Server CAS server is responsible for completing the certification work for the user, CAS server needs to be deployed independently, there is more than one kind of CAS server implementation, Yale CAS server and Esup CAS server is a good choice. CAS Server handles credentials such as username/password (Credentials), which may retrieve a user account information to the database, or retrieve the user's password in an XML file, in this way, CAS provides a flexible but identical interface/implementation separation method, CAS is The authentication method used is separate from the CAS protocol, that is, the implementation details of this authentication can be customized and expanded.l CAS Client CAS client is responsible for deploying on the client (note that I refer to the Web application), in principle, the deployment of CAS client means that when there is a request for access to a protected resource for a local WEB application, and that the requestor needs to be authenticated, the Web app no longer accepts any user name passwords like C Redentials, but redirects to CAS Server for authentication. At present, CAS client support (some in the perfect) very many clients, including Java,. Net, ISAPI, PHP, Perl, Uportal, Acegi, Ruby, VBScript and other clients, almost can say, CAS Protocols can be adapted to client applications written in any language. Parsing a protocol is like dissecting a design pattern, and sometimes the protocol makes a person feel confused. The CAs proxy pattern is relatively complex, it introduces some new concepts, and I want to be able to describe its rationale here, to help readers have a clearer idea of configuring and debugging CAS SSO. If you remember correctly, the CAS protocol should beDrew MazurekResponsible for the development, from CAS v1 to the present CAS V3, the entire protocol is based on the idea of the method of the note is Kerberos. CAS v1 very primitive, sending a user name incredibly "Yes david.turing" way, CAS v2 began to use the XML specification, greatly enhanced the extensibility, CAS V3 began to use AOP technology, so that Spring enthusiasts can easily configure the CAS Se RVer to existing application environments. CAS is obtained through the TGT (Ticket granting Ticket) to obtain St (service Ticket), through St to access the service, and CAS also have corresponding TGT, ST's entities, and they in the method of protecting the TGT although there are differences, but, Ultimately, you can do this-with the hassle of not having to log in multiple times. Below, let's look at the basic protocol framework for CAS: the underlying protocol
cas Basic Mode is the most basic CAS protocol that CAS client uses to filter protected resources for Web applications, filtering every Web request coming from the client, and CAS client parses the HTTP request for a packet Request Service Ticket (Ticket in), if not, indicates that the user is not certified, and CAS Client redirects the user request to CAS Server (Step 2). Step 3 is the user authentication process, and if the user provides the correct Credentials, CAS Server generates a random Service Ticket, then caches the Ticket and redirects the user to the CAS Client (with the Se generated just Rvice Ticket), the Service Ticket is not to be forged, and finally, Step 5 and STEP6 is a verification of the user's identity between CAs Client and CAs Server, with Ticket to Username, Because Ticket is produced by CAS server, therefore, the judgment of CAS server is beyond doubt. This protocol completes a very simple task, that is, User (david.turing) opens IE, direct access to the HelloService application, it is immediately redirected to CAS Server for authentication, User may feel that the browser is HelloseRedirection between Rvcie and Casserver, but User is not seen, the Service Ticket verification (Validation) process between CAs Client and CAS Server. When CAs Server informs CAs client that the service Ticket corresponds to a solid identity, the CAS client serves the current Request user. cas how to achieve sso when our Web age is still at an early stage, SSO is done by sharing cookies, for example, the following three domains Sso:http://www.blogjava.nethttp://www.matrix.org.cnhttp://www.csdn.netIf the three applications are integrated through CAS, then these three domain names will have to do some domain mapping,http://blogjava.cas.orghttp://matrix.cas.orghttp://csdn.cas.orgBecause it is the same domain, each site is able to share cas.org-based cookies. This method is primitive, inflexible and has a lot of security risks, has been abandoned. CAs can be very simple to achieve cross-domain SSO, because, the single point is controlled in the CAS server, the user's most valuable tgc-cookie is only related to CAS server, CAS server only one, therefore, to solve the problem of cookies can not cross-domain. Back to the basic protocol diagram of CAs, when STEP3 is complete, CAS Server sends a Ticket granting cookie (TGC) to the user's browser, which is similar to the TGT of Kerberos , the next time the user is redirected to CAS server by HELLOSERVICE2, CAS server will proactively get to this TGC cookie and do the following: 1,if the User is holding TGC and it hasn't expired, then go to the Step4 of the basic protocol diagram to achieve the SSO effect. 2,If the TGC fails, the user will still have to re-authenticate (take the Step3 of the underlying protocol diagram).
Agent mode for CASMode 1 has been able to meet most of the simple SSO applications, and now we're exploring a more complex case where the user accesses HelloService, and HelloService relies on helloservice2 to get some information, like this: Useràhelloservi Ceàhelloservice2 in this case, assuming that Helloservice2 also needs to be authenticated to the user in order to access it, the CAS introduces a Prox to not affect the users ' experience (excessive redirection causes the user's IE window to flicker constantly). Y authentication mechanism, that is, CAS Client can delegate users to access other WEB applications. The agent is premised on the need for CAS Client to have the user's identity information (similar credentials). Rather than the TGC that we mentioned before is a user's credentials to hold their own identity information, the PGT here is a credential held by the CAS Client for the identity of the user. With TGC, user can eliminate the need to enter a password for service Ticket to access other services, so here, with PGT, the Web app can proxy users to achieve back-end authentication without the involvement of the front-end user. As shown in the following CAS Proxy diagram, CAS client provides an additional PGT URL to the CAS server on top of the underlying protocol, so CAS server can provide a PGT to the CAS client via the PGT URL.
Beginners may be confused about the PGT URL, or ask, why is it so troublesome to pass an additional URL (and SSL's entry) to the PGT? If you return directly in Step 6, you can omit the Pgtiou for the corresponding relationship. Pgtiou design is from security considerations, very necessary, CAS protocol security issues I'll cover it in a later section. So, CAS client got PGT (PGTIOU-85.....TI2TD), this PGT with TGC same key, CAS client can be authenticated by PGT back-end WEB application. As shown, proxy authentication and common authentication is not very different, STEP1, 2 and the basic mode of Step almost the same, the only difference is that the proxy mode is PGT instead of TGC, proxy Ticket (PT) instead of Service Ticket. The end result is that Helloservice2 understands that HelloService is acting as a client of David. Turing, at the same time, according to the local strategy, HELLOSERVICE2 has the obligation to serve the Pgturl=http://helloservice/proxy (Pgturl is used to represent a proxy service), so it passes the data to Helloservi Ce. In this way, HelloService completes a proxy role and assists the User in returning the data he wants.
The proxy authentication mode is very useful, and it is also one of the biggest changes in the CAS Protocol V2, which is ideal for applying SSO in complex business areas. Because, in the past, when we implemented SSO, we assumed that visitors with IE User SSO were ignoring the business system as the visitor role for SSO.
CAS Cross-domain principle
