Andrew,
Thank you for taking the time to give a detailed response.
I think the client libraries are just fine and will serve the purpose. The
reason I am considering manual login is as follows- 1) I am in a situation
where CAS may be deployed into a closed system, meaning, once CAS and other
webapps are deployed, the config files (web.xml etc) are not accessible. 2)
There will be no administrator that will manage the system and that can go in
and set up serverName, validateUrl etc within the config files. So everything
that needs to be setup has to be setup before the system is deployed or I
should be able to set things up programatically after the system is installed.
The suggestion I received (from Scott, I believe) is that I
could consider modifying CASFilter to read config values (serverName etc) from
a different trusted source (rather than from FilterConfig, as it does now) and
use those instead. Thats a good suggestion and we may end up doing that.
However, doing a manual login was another possible solution that doesn't
require modifications to CASFilter and I am exploring that. (Just to be clear-
when I am manually logging in, I can programatically determine the validateUrl,
serverName etc from within my webapp at RUNTIME and use those. No installation
time config changes are required).
The logic you mentioned that looks for the username -
[
Check for authenticated username in the session
If username found
display page appropriate to authenticated user
Get ticket parameter
if ticket is null
redirect to CAS login with service={the page's URL}
validate ticket
if ticket validates
store authenticated username into session
display page appropriate to user authenticated by ticket
else
redirect to CAS with service={the page's URL}&renew=true
]
This seems like what I want. This bounces every request off of CAS, just as you
mentioned and doesn't require the user to type in the password if the session
is active. The only point thats unclear is who is taking care of deleting the
username from the session? I see when it gets set (when ticket is valid) but
not when its removed from the session (it has to be removed somewhere to make
the test for its existence meaningful). It doesn't look like CAS will delete it
since it doesn't know about a custom/marker field stored by the application
within a session. So, where is it deleted?
Thanks.
----- Original Message ----
From: Andrew William Petro <[EMAIL PROTECTED]>
To: Yale CAS mailing list <[email protected]>
Sent: Tuesday, April 10, 2007 4:16:29 PM
Subject: Re: Questions about manual login process..
> Any thoughts, Scott/Andrew?
I think it is best to use a client library for CAS integration.
> may need to add manual login to my webapp (meaning, not use the
web.xml method or jsp tag library)
Why? Assuming this is a Java web application, in what way is the
CASFilter not sufficient?
> Basically, I want to make sure that whether the user goes to Page2
via
Page1
> or directly, he is always going to be authenticated.
> So, here is
the logic that EVERY page executes-
[
Get ticket parameter
if ticket is null
redirect to CAS login with renew=FALSE
Get ticket parameter
validate ticket
if user is authenticated
display page
else
redirect to CAS with renew=TRUE
]
You can look at the CASFilter for an outline of the desired logic here.
If you want to "bounce the user off of CAS" on every page click, this
logic at the top of every page does it:
[
Get ticket parameter
if ticket is null
redirect to CAS login with service={the page's URL}
validate ticket
if ticket validates
display page appropriate to user authenticated by ticket
else
redirect to CAS with service={the page's URL}&renew=true
]
If you don't want to use CAS's "renew" feature, you needn't specify
renew=false, you can just omit the parameter. The renew=true on that
last redirect is useful for avoiding an infinite loop of redirecting
back and forth between CAS and your application with CAS issuing
tickets that then fail to validate, e.g. because your app is
misconfigured as to validation URL.
You don't need to use CAS's "renew" feature to get a valid ticket, you
only need to use it if you want to ensure that the user strongly
authenticated (typically, typed in password) in order to access your
page. Using the "renew" feature in an application that gets and
validates a new ticket on every page access yields an annoying user
experience of constantly having to type the password.
CAS is an authenticated session broker, not an authenticated session
manager. Which is to say, CAS is the trusted intermediary whereby a
user establishes an authenticated session with your application. Your
application is then intended to carry forward that authenticated
session, managing it however it needs to be managed. Your application
is intended to recognize the authenticated user on subsequent requests
after initial CAS authentication is established.
If you follow this practice, then the logic is more like:
[
Check for authenticated username in the session
If username found
display page appropriate to authenticated user
Get ticket parameter
if ticket is null
redirect to CAS login with service={the page's URL}
validate ticket
if ticket validates
store authenticated username into session
display page appropriate to user authenticated by ticket
else
redirect to CAS with service={the page's URL}&renew=true
]
> If there is no ticket and I redirect to CAS with renew=false, I
will be REQUIRED to login- is that a correct statement?
Probably not the way you mean.
If you redirect to CAS and do not specify renew=true, CAS will look for
a secure SSO session cookie ("ticket granting ticket") in th web
browser request. If it is present and valid, CAS will issue a service
ticket on that basis and redirect back to your application without
displaying a login user experience. If you specify renew=true on the
request, then CAS will present the login form regardless of the
presence of a valid ticket granting ticket.
Andrew
http://support.unicon.net/
webzo wrote:
Any
thoughts, Scott/Andrew?
-----
Original Message ----
From: webzo <[EMAIL PROTECTED]>
To: Yale CAS mailing list <[email protected]>
Sent: Thursday, April 5, 2007 10:17:13 AM
Subject: Re: Questions about manual login process..
Hmm,
check the session for what? Is there a way to check if the session is
still valid? If there is, then my logic would become-
Check if session is valid
if valid
display page
else
redirect to CAS login with renew=TRUE
Get ticket parameter
validate ticket
if user is authenticated
display page
else
redirect to CAS again with renew=TRUE
Thanks.
-----
Original Message ----
From: Scott Battaglia <[EMAIL PROTECTED]>
To: Yale CAS mailing list <[email protected]>
Sent: Wednesday, April 4, 2007 7:54:17 PM
Subject: Re: Questions about manual login process..
Is there a reason you're not checking the session at all?
-Scott
On 3/29/07, webzo <[EMAIL PROTECTED]
> wrote:
I
may need to add manual login to my webapp (meaning, not use the web.xml
method or jsp tag library). Just to be sure that I am covering all
bases, I have described the logic I have used below. Can someone
confirm that it sounds ok?
Say there are 2 pages, Page1 and Page2. There is a link to Page2 from
Page1. Basically, I want to make sure that whether the user goes to
Page2 via Page1 or directly, he is always going to be authenticated.
So, here is the logic that EVERY page executes-
Get ticket parameter
if ticket is null
redirect to CAS login with renew=FALSE
Get ticket parameter
validate ticket
if user is authenticated
display page
else
redirect to CAS with renew=TRUE
I am mostly concerned about passing renew=FALSE the first time because
that makes CAS reuse a previous SSO session. I think I need to do this
because if the user gets to Page2 from Page1, then ticket will be null.
But I should not require the user to sign in again because he just did
to enter Page1.
If there is no ticket and I redirect to CAS with renew=false, I will be
REQUIRED to login- is that a correct statement?
Thanks for your time.
Need Mail bonding?
Go to the
Yahoo! Mail Q&A for
great tips from Yahoo! Answers users.
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
Don't get soaked. Take a
quick peek at the forecast
with theYahoo!
Search weather shortcut.
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
Get your own web address.
Have a HUGE year through Yahoo!
Small Business.
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
