CAS ask me for authentication evey time

Wed Jul 5 03:56:45 EDT 2006

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: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu] 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:

<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: [ServletEvent at 16b4e30 source =
org.apache.catalina.connector.RequestFacade at 25753d, 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:
org.jasig.cas.authentication.principal.UsernamePasswordCredentials at 79a340[us
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
UsernamePasswordCredentials at 79a340[userName=usuarioldap2]>

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 [Event at 1e5627c source =
org.jasig.cas.web.flow.GenerateServiceTicketAction at e56328, 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 [Event at d98b00 source =
org.jasig.cas.web.flow.TicketGrantingTicketExistsAction at 1ed7524, 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
cas at tp.its.yale.edu
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.