Andrew, many thanks for your extensive answer. After reading carefully your explanation and focusing in the cookie issue, I think I have solved my problem (I have deduced from your answer it was just the normal behaviour).
I have rolled back the parameter in "serviceTicketExpirationPolicy" to "1". I did that because I thought the ticket was reused by all the applications that tried to authenticate against the CAS server, but your answer is very clarifying. In the cas-servlet.xml file I have modified the bean "ticketGrantingTicketCookieGenerator" changing the parameter "cookieMaxAge" from "-1" (cookie not persistent, deleted when client shuts down) to a positive time value (i.e. "1800", half an hour). Please let me know if there is something wrong with this solution. A question... is there any "user guide" or "configuration guide" or something similar where you can find the options you can set up when deploying your server? It is because the Javadoc of the beans is harder to follow for a system administrator and my questions are more... what is cas-servlet.xml for? What can I change in auditTrailContext.xml? How could I do ...? And yes, I was opening different browser instances (no tabs or new windows within a browser). In this sense, there is something I don't understand: > Depends on exactly what you mean by open another browser. If you mean > another browser window or tab within the same web browser application, > then yes, you should have a CAS Ticket Granting Cookie secure session > cookie which authenticates your browser to CAS allowing it to issue you a > new Service Ticket for each time you're accessing the application, > authenticating you each time. I thought the whole point of a SSO was that you can open different browser instances (or even close all the browsers and five minutes later open a new one) and you were still authenticated. If you open new tabs (in firefox) or "new windows" in IE, you are sharing the same session ID, so you are already authenticated, even if you are not using SSO at all... I tried it yesterday and Acegi didn't redirect me to CAS, because from the server side both tabs are the same client (it doesn't have any way to distinguish them). Don't worry about the password thing, I was just making a "proof of concept" in our own private network, and the application just shows a "Hello World!" message... nothing worth to hack it! :) But it is good to see you have created a JIRA issue. BTW, I was trying to use "HTTPLook" to monitor the HTTP communication and see if the cookie was present, but I did't manage to get it works with HTTPS... do you know any https sniffer or tool to see those things? Just one more thing (not related with this issue) The Spanish translations are quite... strange (they sound like me when I speak English). I think most of the native Spanish speakers will agree with this... I know in a 90% of the cases you will replace the CAS screens with your own ones, so it is not an important issue, but I can send you a more "accurate" (form my own point of view) translation if you think it could be useful. Thanks for your kind answer, José Luis. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Andrew Petro Enviado el: martes, 04 de julio de 2006 22:16 Para: 'Yale CAS mailing list' Asunto: RE: CAS ask me for authentication evey time Jose, > I'm very new with CAS Welcome. > I've configured a CAS server (3.0.4) which > successfully starts and authenticate users against a LDAP server. > I'm using an Acegi secured application as CAS client. > First time I try to access the application, the CAS login screen appears, > then I enter the username and password and I'm redirected to my application main page. > But, If I open a second browser and try to enter into the application, > the CAS login screen is shown again... shouldn't be I already authenticated? > Same happens with a third, fourth,... browser. Depends on exactly what you mean by open another browser. If you mean another browser window or tab within the same web browser application, then yes, you should have a CAS Ticket Granting Cookie secure session cookie which authenticates your browser to CAS allowing it to issue you a new Service Ticket for each time you're accessing the application, authenticating you each time. > I've changed this parameter (from value 1 to value 1000) > in the serviceTicketExpirationPolicy bean: <!-- This argument is the number of times that a ticket can be used before its considered expired. --> <constructor-arg index="0" value="1000" /> I don't think you wanted to do that. I've forgotten why this is configurable, why you'd ever want a service ticket to be multiply usable. Service tickets are a quick transactional authentication token whereby you bootstrap general CAS SSO authentication to a specific authenticated session with your web application. Your web application should then manage its own authenticated session and not require that particular service ticket to be multiply validatable. The problem you're having isn't that the service ticket expired, presumably -- the problem you're having is that CAS is failing to recognize the browser as authenticated and so is again presenting the opportunity to authenticate. > BTW, I can't see any cookie in my "temporal internet files" > when I login... Should I have got one? No. CAS uses a secure session cookie which should be stored only in memory and never written to disk. When your browser session ends, the cookie is supposed to disappear and you'll have to authenticate to CAS again to establish a new SSO session. You should get this secure session scoped cookie and it would be worth checking in your web browser to verify that the CASTGC cookie is being set successfully. Narration of snippets of your log: > 'noTicketGrantingTicketExists', stateId = [null], parameters = [null]]> Didn't find an existing Ticket Granting Cookie. Therefore must display the login screen so the end user can establish a new authenticated CAS SSO session. > 'authenticationRequired', stateId = [null], parameters = [null]]> Gateway parameter is not present, so authentication is required, so CAS will display the login screen. //LOGIN SCREEN IS SHOWN, AND I ENTER MY IDENTIFICATION <Binding allowed parameters in event: [EMAIL PROTECTED] source = [EMAIL PROTECTED], id = 'submit', stateId = 'viewLoginForm', parameters = map['password' -> 'ho[ANDREW_MODIFIED_TO_AVOID_REPOSTING_PASSWORD_TO_LIST]do', 'service' -> 'https://Tomcat:9443/psegldap/j_acegi_cas_security_check', 'lt' -> '1BCECD27-9043-84C1-F980-20F4F9911C55', 'username' -> 'usuarioldap2', '_currentStateId' -> 'viewLoginForm', '_eventId' -> 'submit']] to form object with name: 'credentials', prebind-toString: [EMAIL PROTECTED] erName=<null>]> Note that CAS logged your password here. I would have to admit I didn't know it was doing that. I've opened a JIRA issue to track this. It is certainly a behavior that we should document aggressively. If that was a production password, Jose, you need to change it right now, since you've emailed it to a public list. http://www.ja-sig.org/issues/browse/CAS-376 The form post included the username and password, which CAS will bind into the UsernamePasswordCredentials, the "lt" "login ticket", which helps prevent repeat form submission, and the URL of the service to which you're trying to authenticate. This all looks good. 2006-07-04 09:19:00,847 DEBUG [org.jasig.cas.web.flow.AuthenticationViaFormAction] - <There are [0] errors, details: []> No errors in bringing up the credentials object, great. > <Attempting to create TicketGrantingTicket for [EMAIL PROTECTED]> CAS is going to try to set a cookie that will authenticate the browser to CAS on subsequent requests: > <Added ticket [TGT-5-2y6VvZzptFO3CzY2ReXZ3ADKFlBexNKuRbg-50] to registry.> Okay, server-side CAS registered the ticket granting cookie keying to your authenticated information (username). Now it just needs to get a corresponding cookie to your browser. > SecureCookieGenerator] - <Added cookie with name [CASTGC] and value [TGT-5-2y6VvZzptFO3CzY2ReXZ3ADKFlBexNKuRbg-50]> CAS thinks it set the cookie correctly. 2006-07-04 09:19:01,207 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to retrieve ticket [TGT-5-2y6VvZzptFO3CzY2ReXZ3ADKFlBexNKuRbg-50]> 2006-07-04 09:19:01,207 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Ticket [TGT-5-2y6VvZzptFO3CzY2ReXZ3ADKFlBexNKuRbg-50] found in registry.> 2006-07-04 09:19:01,207 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Added ticket [ST-4-fckOryQeHJUl0HmQ23L2H0FZ4cKQtBA0tqa-20] to registry.> 2006-07-04 09:19:01,207 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-4-fckOryQeHJUl0HmQ23L2H0FZ4cKQtBA0tqa-20] for service [https://Tomcat:9443/psegldap/j_acegi_cas_security_check] for user [usuarioldap2]> 2006-07-04 09:19:01,207 DEBUG [org.jasig.cas.web.flow.GenerateServiceTicketAction] - <Action 'org.jasig.cas.web.flow.GenerateServiceTicketAction' completed execution; result event is [EMAIL PROTECTED] source = [EMAIL PROTECTED], id = 'success', stateId = [null], parameters = [null]]> It then used the ticket granting ticket to generate a service ticket for authenticating to your application. 2006-07-04 09:19:01,222 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to retrieve ticket [ST-4-fckOryQeHJUl0HmQ23L2H0FZ4cKQtBA0tqa-20]> 2006-07-04 09:19:01,222 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Ticket [ST-4-fckOryQeHJUl0HmQ23L2H0FZ4cKQtBA0tqa-20] found in registry.> //THE APPLICATION SCREEN IS SHOWN //I OPEN A NEW BROWSER AND ENTER THE APPLICATION URL AND A NEW CAS LOGIN SCREEN IS SHOWN AGAIN TicketGrantingTicketExistsAction] - <Action 'org.jasig.cas.web.flow.TicketGrantingTicketExistsAction' beginning execution> TicketGrantingTicketExistsAction] - <Action 'org.jasig.cas.web.flow.TicketGrantingTicketExistsAction' completed execution; result event is [EMAIL PROTECTED] source = [EMAIL PROTECTED], id = 'noTicketGrantingTicketExists', stateId = [null], parameters = [null]]> CAS didn't find the ticket granting ticket in your browser. So the questions are: are you not accessing CAS via SSL? Exactly what URL are you running your CAS server on, and does the CAS ticket granting cookie path match the configured path for your CAS instance? Is your browser configured not to accept these cookies? As a next step, I'd suggest verifying that you're receiving a CASTGC cookie in your browser. Andrew _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas ------------------------------------------------------------------------------------------------------------------- Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL. The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL. _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
