CAS ask me for authentication evey time

Tue Jul 4 16:16:07 EDT 2006

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