diff --git a/docs/manual/src/docbook/cas-auth-provider.xml b/docs/manual/src/docbook/cas-auth-provider.xml index 4ac2652a89..20095763f0 100644 --- a/docs/manual/src/docbook/cas-auth-provider.xml +++ b/docs/manual/src/docbook/cas-auth-provider.xml @@ -17,34 +17,30 @@ How CAS Works Whilst the CAS web site contains documents that detail the architecture of CAS, we - present the general overview again here within the context of Spring Security. Spring - Security 3.0 supports CAS 3. At the time of writing, the CAS server was at version - 3.3. + present the general overview again here within the context of Spring Security. Spring Security + 3.0 supports CAS 3. At the time of writing, the CAS server was at version 3.4. Somewhere in your enterprise you will need to setup a CAS server. The CAS server is simply a standard WAR file, so there isn't anything difficult about setting up your server. Inside the WAR file you will customise the login and other single sign on pages displayed to users. - When deploying a CAS 3.3 server, you will also need to specify an - AuthenticationHandler in the - deployerConfigContext.xml included with CAS. The - AuthenticationHandler has a simple method that returns a boolean as - to whether a given set of Credentials is valid. Your - AuthenticationHandler implementation will need to link into some type - of backend authentication repository, such as an LDAP server or database. CAS itself - includes numerous AuthenticationHandlers out of the box to assist - with this. When you download and deploy the server war file, it is set up to - successfully authenticate users who enter a password matching their username, which is - useful for testing. + When deploying a CAS 3.4 server, you will also need to specify an + AuthenticationHandler in the + deployerConfigContext.xml included with CAS. The + AuthenticationHandler has a simple method that returns a boolean as to + whether a given set of Credentials is valid. Your AuthenticationHandler + implementation will need to link into some type of backend authentication repository, such as + an LDAP server or database. CAS itself includes numerous + AuthenticationHandlers out of the box to assist with this. When you + download and deploy the server war file, it is set up to successfully authenticate users who + enter a password matching their username, which is useful for testing. Apart from the CAS server itself, the other key players are of course the secure web - applications deployed throughout your enterprise. These web applications are known as - "services". There are two types of services: standard services and proxy services. A - proxy service is able to request resources from other services on behalf of the user. - This will be explained more fully later. - - Back on the CAS server, the proxy validation request will be + Back on the CAS server, the validation request will be received. If the presented service ticket matches the service URL the ticket was issued to, CAS will provide an affirmative response - in XML indicating the username. If any proxy was involved in the + in XML indicating the username. - + - The CasProxyTicketValidator will parse - the XML received from the CAS server. It will return to the - CasAuthenticationProvider a - TicketResponse, which includes the username - (mandatory), proxy list (if any were involved), and proxy-granting - ticket IOU (if the proxy callback was requested). + The Cas20TicketValidator will parse the XML received from the + CAS server. It will return to the CasAuthenticationProvider a + TicketResponse, which includes the username (mandatory). - + - CasAuthenticationProvider will next - request a CasAuthoritiesPopulator to advise the + CasAuthenticationProvider will next + request a AuthenticationUserDetailsService to load the GrantedAuthority objects that apply to the user - contained in the TicketResponse. Spring - Security includes a DaoCasAuthoritiesPopulator - which simply uses the UserDetailsService - infrastructure to find the UserDetails and - their associated GrantedAuthoritys. Note that - the password and enabled/disabled status of - UserDetails returned by the - UserDetailsService are ignored, as the CAS - server is responsible for authentication decisions. - DaoCasAuthoritiesPopulator is only concerned - with retrieving the GrantedAuthoritys. + contained in the Assertion. If there were no problems, - CasAuthenticationProvider constructs a - CasAuthenticationToken including the details - contained in the TicketResponse and the - GrantedAuthoritys. The - CasAuthenticationToken contains the hash of a - key, so that the CasAuthenticationProvider - knows it created it. + CasAuthenticationProvider constructs a + CasAuthenticationToken including the details + contained in the TicketResponse and the + GrantedAuthoritys. Control then returns to - CasProcessingFilter, which places the created - CasAuthenticationToken into the - HttpSession attribute named - HttpSessionContextIntegrationFilter.SPRING_SECURITY_CONTEXT_KEY. + CasAuthenticationFilter, which places the created + CasAuthenticationToken in the security context. The user's browser is redirected to the original page that - caused the AuthenticationException. - - - - As the Authentication object is now in - the well-known location, it is handled like any other - authentication approach. Usually the - HttpSessionContextIntegrationFilter will be - used to associate the Authentication object - with the SecurityContextHolder for the duration - of each request. + caused the AuthenticationException (or a + custom destination depending on + the configuration). - It's good that you're still here! It might sound involved, but - you can relax as Spring Security classes hide much of the complexity. - Let's now look at how this is configured + It's good that you're still here! Let's now look at how this is configured ---> +
@@ -325,13 +283,16 @@ ... ]]> - The - CasAuthenticationProvider uses a + The CasAuthenticationProvider uses a UserDetailsService instance to load the authorities for a - user, once they have been authentiated by CAS. We've shown a simple in-memory setup + user, once they have been authenticated by CAS. We've shown a simple in-memory setup here. - The beans are all reasonable self-explanatory if you refer back to the "How CAS Works" - section. + The beans are all reasonably self-explanatory if you refer back to the + How CAS Works section. + This completes the configuration of CAS. If you haven't made any + mistakes, your web application should happily work within the + framework of CAS single sign on. No other parts of Spring Security + need to be concerned about the fact CAS handled authentication.
+