From 302ae5a391aac3da05fd2fbb8ae09a98b512e09f Mon Sep 17 00:00:00 2001 From: Ben Alex Date: Tue, 20 Apr 2004 23:49:16 +0000 Subject: [PATCH] Spelling and minor changes to CAS section. --- docs/reference/src/index.xml | 158 ++++++++++++++++++++--------------- 1 file changed, 92 insertions(+), 66 deletions(-) diff --git a/docs/reference/src/index.xml b/docs/reference/src/index.xml index 9d6b0b70ab..88c67968ce 100644 --- a/docs/reference/src/index.xml +++ b/docs/reference/src/index.xml @@ -2161,7 +2161,7 @@ $CATALINA_HOME/bin/startup.sh the architecture of CAS, we present the general overview again here within the context of the Acegi Security System for Spring. The following refers to CAS 2.0, being the version of CAS that Acegi - Security for Spring supports. + Security System for Spring supports. 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 @@ -2173,7 +2173,7 @@ $CATALINA_HOME/bin/startup.sh boolean as to whether a given username and password is valid. Your PasswordHandler implementation will need to link into some type of backend authentication repository, such as an LDAP - server or database. + server or database. If you're running an existing CAS server, you will have already established a PasswordHandler. If you have not, @@ -2183,8 +2183,8 @@ $CATALINA_HOME/bin/startup.sh AuthenticationManager, enabling you to use a security configuration you might already have in place. You do not need to use the CasPasswordHandler class on your - CAS server unless you do not wish. The Acegi Security System for - Spring will function as a CAS client successfully irrespective of the + CAS server if you do not wish. The Acegi Security System for Spring + will function as a CAS client successfully irrespective of the PasswordHandler you've chosen for your CAS server. @@ -2200,9 +2200,9 @@ $CATALINA_HOME/bin/startup.sh contains a clients archive which demonstrates CAS clients in Java, Active Server Pages, Perl, Python and others. Naturally, Java support is very strong given the CAS server is written in Java. You do not - need to use one of CAS' clients to interact with the CAS server from - Acegi Security System for Spring secured applications. This is handled - transparently for you. + need to use any of CAS' client classes in applications secured by the + Acegi Security System for Spring. This is handled transparently for + you. The basic interaction between a web browser, CAS server and an Acegi Security for System Spring secured service is as follows: @@ -2216,26 +2216,26 @@ $CATALINA_HOME/bin/startup.sh The user eventually requests a page that is either secure or one of the beans it uses is secure. Acegi Security's - SecurityEnforcementFilter will detect the - AuthenticationException. + SecurityEnforcementFilter will detect the + AuthenticationException. - Because the user has no Authentication - object in - HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY, - the SecurityEnforcementFilter will call the configured - AuthenticationEntryPoint. If using CAS, this - will be the CasProcessingFilterEntryPoint - class. + Because the user's Authentication object + (or lack thereof) caused an + AuthenticationException, the + SecurityEnforcementFilter will call the + configured AuthenticationEntryPoint. If using + CAS, this will be the + CasProcessingFilterEntryPoint class. - The CasProcessingFilterEntry point will redirect the user's - browser to the CAS server. It will also indicate a - service parameter, which is the callback URL - for the Acegi Security service. For example, the URL the browser - is redirected to might be + The CasProcessingFilterEntry point will + redirect the user's browser to the CAS server. It will also + indicate a service parameter, which is the + callback URL for the Acegi Security service. For example, the URL + the browser is redirected to might be https://my.company.com/cas/login?service=https://server3.company.com/webapp/j_acegi_cas_security_check. @@ -2245,8 +2245,8 @@ $CATALINA_HOME/bin/startup.sh session cookie which indicates they've previously logged on, they will not be prompted to login again (there is an exception to this procedure, which we'll cover later). CAS will use the - PasswordHandler discussed above to decide whether the username and - password is valid + PasswordHandler discussed above to decide + whether the username and password is valid. @@ -2273,10 +2273,10 @@ $CATALINA_HOME/bin/startup.sh - The AuthenticationManager implementation will be the - ProviderManager, which is in turn configured - with the CasAuthenticationProvider. The - CasAuthenticationProvider only responds to + The AuthenticationManager implementation + will be the ProviderManager, which is in turn + configured with the CasAuthenticationProvider. + The CasAuthenticationProvider only responds to UsernamePasswordAuthenticationTokens containing the CAS-specific principal (such as CasProcessingFilter.CAS_STATEFUL_IDENTIFIER) @@ -2288,34 +2288,34 @@ $CATALINA_HOME/bin/startup.sh CasAuthenticationProvider will validate the service ticket using a TicketValidator implementation. Acegi Security includes one implementation, the - CasProxyTicketValidator. This implementation - uses a CAS-supplied ticket validator. The + CasProxyTicketValidator. This implementation a + ticket validation class included in the CAS client library. The CasProxyTicketValidator makes a HTTPS request to the CAS server in order to validate the service ticket. The CasProxyTicketValidator may also include a - proxy callback parameter, which is included in this example: + proxy callback URL, which is included in this example: https://my.company.com/cas/proxyValidate?service=https://server3.company.com/webapp/j_acegi_cas_security_check&ticket=ST-0-ER94xMJmn6pha35CQRoZ&pgtUrl=https://server3.company.com/webapp/casProxy/receptor. - Back of the CAS server, the proxy validation request will be + Back on the CAS server, the proxy validation request will be received. If the presented service ticket matches the service URL - requested initially, CAS will provide an affirmative response in - XML indicating the username. If any proxy was involved in the + the ticket was issued to, CAS will provide an affirmative response + in XML indicating the username. If any proxy was involved in the authentication (discussed below), the list of proxies is also included in the XML response. [OPTIONAL] If the request to the CAS validation service - included the pgtUrl, CAS will include a - pgtIou string in the XML response. This - pgtIou represents a proxy-granting ticket IOU. - The CAS server will then create its own HTTPS connection back to - the pgtUrl. This is to mutually authenticate - the CAS server and the claimed service. The HTTPS connection will - be used to send a proxy granting ticket to the original web - application. For example, + included the proxy callback URL (in the pgtUrl + parameter), CAS will include a pgtIou string in + the XML response. This pgtIou represents a + proxy-granting ticket IOU. The CAS server will then create its own + HTTPS connection back to the pgtUrl. This is to + mutually authenticate the CAS server and the claimed service URL. + The HTTPS connection will be used to send a proxy granting ticket + to the original web application. For example, https://server3.company.com/webapp/casProxy/receptor?pgtIou=PGTIOU-0-R0zlgrl4pdAQwBvJWO3vnNpevwqStbSGcq3vKB2SqSFFRnjPHt&pgtId=PGT-1-si9YkkHLrtACBo64rmsi3v2nf7cpCResXg5MpESZFArbaZiOKH. We suggest you use CAS' ProxyTicketReceptor servlet to receive these proxy-granting tickets, if they are @@ -2448,9 +2448,10 @@ $CATALINA_HOME/bin/startup.sh <property name="authenticationManager"><ref bean="authenticationManager"/></property> </bean> - Note the granted authorities are ignored by CAS. It has no way - of communciating the granted authorities to calling applications. CAS - is only concerned with username and passwords. + Note the granted authorities are ignored by CAS because it has + no way of communicating the granted authorities to calling + applications. CAS is only concerned with username and passwords (and + the enabled/disabled status). Next you will need to edit the existing /web/WEB-INF/web.xml file. Add (or edit in the case @@ -2478,6 +2479,12 @@ $CATALINA_HOME/bin/startup.sh the directory structure. This will create /lib/cas.war, which is ready for deployment to your servlet container. + + Note CAS heavily relies on HTTPS. You can't even test the system + without a HTTPS certificate. Whilst you should refer to your web + container's documentation on setting up HTTPS, if you need some + additional help or a test certificate you might like to check the + samples/contacts/etc/ssl directory. @@ -2549,12 +2556,12 @@ $CATALINA_HOME/bin/startup.sh For CAS to operate, the SecurityEnforcementFilter must have its authenticationEntryPoint property set to the - CasProcessingFilterEntryPoint bean. + CasProcessingFilterEntryPoint bean. The CasProcessingFilterEntryPoint must refer - to the ServiceProperties bean (discussed above) and - provide the URL to the enterprise's CAS login server. This is where - the user's browser will be redirected. + to the ServiceProperties bean (discussed above), + which provides the URL to the enterprise's CAS login server. This is + where the user's browser will be redirected. Next you need to add an AuthenticationManager that uses CasAuthenticationProvider and its @@ -2656,27 +2663,31 @@ $CATALINA_HOME/bin/startup.sh within the context of a HttpSession, it isn't possible to rely on the HttpSession's HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY - attribute to locate the CasAuthenticationToken. Furthermore, because - the CAS server invalidates a service ticket after it has been - validated by the TicketValidator, presenting the same service ticket - on subsequent requests will not work. It is similarly very difficult - to obtain a proxy-granting ticket for a remoting protocol client, as - they are often operational on client machines which do not have HTTPS - certificates that would be trusted by the CAS server. + attribute to locate the CasAuthenticationToken. + Furthermore, because the CAS server invalidates a service ticket after + it has been validated by the TicketValidator, + presenting the same service ticket on subsequent requests will not + work. It is similarly very difficult to obtain a proxy-granting ticket + for a remoting protocol client, as they are often deployed on client + machines which rarely have HTTPS URLs that would be accessible to the + CAS server. One obvious option is to not use CAS at all for remoting protocol clients. However, this would eliminate many of the desirable features of CAS. - As a middle-ground, the CasAuthenticationProvider uses a - StatelessTicketCache. This is used solely for requests with a - principal equal to + As a middle-ground, the + CasAuthenticationProvider uses a + StatelessTicketCache. This is used solely for + requests with a principal equal to CasProcessingFilter.CAS_STATELESS_IDENTIFIER. What - happens is the CasAuthenticationProvider will store the resulting - CasAuthenticationToken in the StatelessTicketCache, keyed on the - service ticket. Accordingly, remoting protocol clients can present the - same service ticket and the CasAuthenticationProvider will not need to - contact the CAS server for validation. + happens is the CasAuthenticationProvider will store + the resulting CasAuthenticationToken in the + StatelessTicketCache, keyed on the service ticket. + Accordingly, remoting protocol clients can present the same service + ticket and the CasAuthenticationProvider will not + need to contact the CAS server for validation (aside from the first + request). The other aspect of advanced CAS usage involves creating proxy tickets from the proxy-granting ticket. As indicated above, we @@ -2794,6 +2805,11 @@ $CATALINA_HOME/bin/startup.sh scott's contacts when authenticating as marissa. To see it work properly, use client scott scott wombat. + + Please note the sample application's client + does not currently support CAS. You can still give it a try, though, if + you're ambitious: try client scott _cas_stateless_ + YOUR-SERVICE-TICKET-ID-FOR-SCOTT. @@ -2837,6 +2853,15 @@ $CATALINA_HOME/bin/startup.sh (use ant clover.html to view coverage) + + Join the acegisecurity-developer and acegisecurity-cvs mailing + lists so you're in the loop + + + + Use CamelCase + + Add a CVS $Id: index.xml,v 1.3 2004/04/02 21:12:25 fbos Exp $ tag to the JavaDocs for any new class you @@ -2858,9 +2883,10 @@ $CATALINA_HOME/bin/startup.sh Further Information Questions and comments on the Acegi Security System for Spring are - welcome. Please direct comments to the Spring Users mailing list or - ben.alex@acegi.com.au. Our project home page (where you can obtain the - latest release of the project and access to CVS) is at + welcome. Please direct comments to the Spring Users mailing list. You're + also welcome to join the acegisecurity-developer mailing list. Our + project home page (where you can obtain the latest release of the + project and access to CVS, mailing lists etc) is at http://acegisecurity.sourceforge.net.