Getting a New Login Ticket (flowExecutionId)

[Scott Battaglia]

Ole,

If you feel you must not do a redirect to CAS (though I agree with Andrew's
statements), one alternative is to construct a smaller view (i.e. just the
login form without anything fancy) and use an iframe to embed the CAS
server's login page on to yours.

It does require some slight modification to the flow (JavaScript needs to be
used for a redirect instead of normal HTTP redirects).  It ends up working
similar to Google Accounts when it is embedded on a page.

-Scott

On Feb 13, 2008 12:45 PM, Ole Ersoy <ole.ersoy at gmail.com> wrote:

> Hi Andrew,
>
> Andrew Petro wrote:
> > Ole,
> >
> > It might be better to let the CAS web application itself render those
> > screens that include the login form, as custom login views and initial
> > states in convergent login web flows (perhaps there's an initial state
> > that brokers out to many alternative login form states that then
> > converge back to shared validation logic).
>
> That would definitely save some time :-).  From an elegance point of view,
> I'd like to be able to eliminate browser login page refreshes.
> >
> > This would allow the CAS application to naturally render working login
> > screens, future-proofing this a bit against any changes in login flow
> > implementation, names of form fields, etc.
>
> Yeah it's definitely easier from a maintenance point of view as well.
>
> >
> > Centrally managing the login forms also has nice properties for your
> > ability to add additional messaging, outage notification, or additional
> > login flow logic, later.
>
> I agree, although we'd like to insert actions that return xhr responses to
> the calling application, rather than redirecting the user to another page,
> thus we're back to square A.
> >
> > All login forms appearing with an https://cas.myschool.edu/login-looking
> > URL has nice properties for end users proofing themselves against
> > phishing attacks by taking care to only give their credentials to the
> > CAS server at its well-known URL.
> Some background just to make sure I understand this correctly:
>
> Start background
> ------------------------------
> >From what I understand phishing happens when someone is tricked into
> going to a totally different server than they think they are going to.  For
> instance, when I go http://chase.com I expect that to be my banking
> server, and that I can enter my user id and password safely.  Someone try to
> phish my credentials, may send me a mail tricking me into going to a page
> that looks like chases page, but really is not.
>
> So I think from a users point of view, they should always check the URL of
> the site that they are going to.  For example, if someone goes to
> http://case.com, and it looks exactly like chase.com, and they enter their
> credentials, the credentials could have been phished.
> ------------------------------
> End background
>
> So I think as long as the webapp that contains the login form runs on the
> same domain that the cas runs on, the user is still safe...unless there's
> something else that I'm unaware of?
> >
> > In short, my suggestion on how login forms not rendered by the CAS
> > server can be accomplished is to not do that.  For whatever it's worth.
>
> Definitely appreciate your points with respect to maintenance, etc.
>  Although sometimes simple solutions pop up, that just make things real
> easy, so I'm keeping my fingers crossed.  At least it gives me some
> motivation to learn Spring Webflow :-).  Thank you for your points though,
>
> - Ole
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>



-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080213/2234c3fd/attachment.html