Maybe you're asking, "How do I take advantage of CAS's gateway feature to transparently pick up a login when the user has a CAS SSO session, thereby providing a maximally authenticated and personalized portal on the very first click" (a topic about which I have some passion and will be visiting in a presentation at the coming Atlanta JA-SIG conference).
To my knowledge, no one has ever done this. But it is in theory quite doable and would be very cool.
Here's how it would work: the CAS Filter has a gateway mode. In gateway mode, it will once per session attempt to pick up a freebie ticket from CAS (no user experience interruption, using the "gateway" protocol feature).
If it succeeds, great, validate the ticket. If it fails, add a session attribute recording this fact so as not to try again on subsequent requests.
That code exists.
Okay, then we'd need a subsequent filter that detected the case where the CAS Filter had done this, and redirected the request to the Login servlet.
And then we'd need a uPortal security context that could detect and retrieve the authenticated user from the session where the CAS Filter put it on the original succeeded freebie authentication. Probably we could just use the existing CASFilteredContext if the subsequent redirect-to-Login filter were sufficiently clever to retain the ticket= parameter on the URL.
And then we'd have to get a few of the details right so that regular CAS authentication still worked and the PGT was available to the security context.
A potential problem is the case where uPortal is the homepage, such that every time the user opens a browser window. It would be important to get the details of that right so that it binds to the same session instead of creating a new session if that's preferable (prevent authenticated session proliferation), or creates a new session if separating state between the two windows is preferable (prevent opening a new browser window from messing up an existing authenticated session). At that point you might have to get clever about detecting when the user navigates away and more aggressively cleaning up these sessions, or setting an initial short session timeout for authenticated sessions and then extending it on a subsequent click in the session (demonstrating that the session is likely a real session rather than a throwaway on the user's way to something else).
Which is to say that, making authenticated sessions more convenient will lead to more authenticated sessions, and this leads to more load and a less favorable runtime memory footprint.
Lots of complexity to navigate here. But potentially, very, very cool.