We saw the same issue with our off-campus hosted Blackboard system.
Sometimes it took 4 or 5 attempts of (correctly) entering credentials to
actually get the page to successfully redirect to the service instead of
sending you back to the login form. Our load balancer is a BigIP F5
BTW. This section of the Troubleshooting Guide was pertinent to
resolving the issue for us:
------------------------------------------------------------------------
Login Form Clearing Credentials on Submission
You may encounter an issue where upon submission of credentials on the
login form, the screen clears the input data and asks the user again to
repopulate the form. The CAS Server log may also indicate the received
login ticket is invalid and therefore unable to accept the
authentication request.
The CAS server itself initiates a web session upon authentication
requests that by default is configured to last for 5 minutes. The state
of the session is managed at server-side and thus, once the session
expires any authentication activity on the client side such as
submission of the login form is disregarded until a new session a
regenerated. *Another possible cause may be related to a clustered CAS
environment where CAS nodes are protected by a load balancer whose
“timeout” is configured less than the default session expiration timeout
of CAS. Thus, once the authentication form is submitted and the request
is routed to the load balancer, it is seen as a new request and is
redirected back to a CAS node for authentication.*
To remedy the problem, the suggestion is to configure the default CAS
session timeout to be an appropriate value that matches the time a given
user is expected to stay on the login screen. Similarly, the same change
may be applied to the load balancer to treat authentication requests
within a longer time span.
------------------------------------------------------------------------
Setting sticky sessions on the load balancer and setting the session
timeout on the load balancer to also be 5 minutes resolved the issue for us.
On 11/11/14 11:04 AM, Sandeep Nagapuri wrote:
> Hi,
>
> Our team has successfully implemented CAS with EhCache for ticket
> registry/replication on our test environment(two servers T1 and T2 behind the
> load-balancer) and everything seems to be working fine until we encountered
> an issue with one of our vendor application(which has its custom login page).
> At sometimes, after the authentication is successful and TGT is created,
> instead of being redirected to the dashboard it is being redirected to the
> default CAS login page.
>
> Observation with simple Java App:
> ```````````````````````````
> We tried repeating this with a simple java application(casified) and it never
> did this. TGT and ST are created on the same server and ST is validated on
> either of the servers successfully and is redirected to the dashboard page.
>
> Observation with Vendor App:
> ```````````````````````
> Sometimes the TGT and ST are created on the same server(one of the two
> servers behind the load-balancer) and everything seems to be working fine.
> Sometime the only TGT is created on one of the servers and we see ST in
> failed to create on another server. TGT should have been replicated by
> EhCache and ST should not fail to get created on the other server too.
>
> I am assume that because of the above observation, it is redirecting to the
> default CAS login page and from there everything is happening properly. I am
> not sure if this is with the vendor application which has a custom login page.
>
> I didn't implement StickySessions and still other applications work properly
> and it is only with this application.
>
> If anyone has undergone this kind of an issue please help me out to resolve
> this.
>
> Thanks,
> Sandeep
>
> --
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
