On Wed, Jan 21, 2009 at 10:21 AM, Keith Garry Boyce <ga...@consultsure.com>wrote:
> 1) Are there any specific examples you can point to with a real life cas > iframe. I see discussion about it but no examples > I'm not sure if anyone's actually done it in production. I've done it with testing. You essentially create a scaled down login page (with the bare minimum username/password/submit) and replace the traditional 301 redirect in the web flow with a JSP page that does a JavaScript redirect (in order to replace the entire page in the web browser). > > 2) I also saw something about telling cas which login page to draw. It says > wind goes this route but again no example. > This can be done via using themes in the Services Management tool in conjunction with the Themes support in Spring. > > 3) I understand that the use case is not in fact overlooked but planned. > But it would seem to me: > a) CAS and other SSO solutions do not provide an out of the box way to > allow an app to customize CAS login page and thus workarounds such as > iframes are necessary. Perhaps it should be made possible to specify a > callback to the app which could paint its own login page with placeholders > for necessary cas artifacts > Again, we purposely don't do this. User education of the appropriate login page (i.e. check the URL and the page itself) are important tools. You can control how much customization you allow via the combination of the Themes tool and the Services Management tool/ > > b)if some application in fact has the TGT then what would be the harm of > issuing a session cookie with that same TGT? Even understanding that it's > not recommended. > A TGT is a token that essentially gives a user the right to access most applications without giving his or her password again. Anything that has that token could access services for the user without having their password. -Scott > > > > ------------------------------ > From: Scott Battaglia <scott.battag...@gmail.com> > Sent: Tuesday, January 20, 2009 9:33 PM > To: Yale CAS mailing list <cas@tp.its.yale.edu> > Subject: Re: CAS without CAS login page using restful api and > modifiedlogin-webflow.xml > > I believe we've answered multiple times that it is NOT recommended to > capture user credentials and submit them and then create a CAS session for > the user. CAS is the only thing that should be creating a CAS session for > the user. Its a security risk for anyone to have the TGT other than the user > and the CAS server. We go through great extends to NOT allow it. > > While you may feel that is a use case that cannot be overlooked, its in > fact a use case we purposely don't do. Are there ways around it? Sure. > Previous discussions have talked about embedding the login page in a form > using something like an IFRAME, which still allows CAS to handle the > credentials (similar to what Google Accounts does). > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > On Tue, Jan 20, 2009 at 5:21 PM, Keith Garry Boyce > <ga...@consultsure.com>wrote: > >> Again. I'd appreciate an answer on this please. >> >> -----Original Message----- >> From: Keith Garry Boyce <ga...@consultsure.com> >> Sent: Saturday, January 17, 2009 8:07 AM >> To: 'Yale CAS mailing list' <cas@tp.its.yale.edu> >> Subject: RE: CAS without CAS login page using restful api and >> modifiedlogin-webflow.xml >> >> Anyone? >> >> > _____________________________________________ >> > From: cas-boun...@tp.its.yale.edu >> > [mailto: >> > > > [The entire original message is not included] > > _______________________________________________ > Yale CAS mailing list > cas@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list cas@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas
