Jose, > Im very new with CAS
Welcome. > Ive configured a CAS server (3.0.4) which > successfully starts and authenticate users against a LDAP server. > Im 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 Im 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 shouldnt 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. > Ive 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 isnt 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 cant 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
