I fully agree with Keith. We are facing the exact same problem. This type of constraint (login page should have the same look and feel as the application) directly comes from the customer side, whether external or internal. As a technical person, of course, I can tell them that it's not how SSO is meant to work, that it would break some of the security features of the software, but as Keith is pointing out, customers dictate certain things that we as developers can't control.
Jean-Noel On 21 Jan 2009, at 20:03, Keith Garry Boyce wrote: > Thanks so much for the feedback. The question of "Why?" > > Usability people decide what they want and if they want the login > page to reflect something about the said application of course we > can go back to them and say would this x way work for you. But if > they say no then should i go back to them and say because we are > using CAS it has to work this way and so it would be a hack to make > it work the way that you want. Perhaps but it seems to me strange > that your security solution should dictate things about useablilty. > > Security is no doubt important but i've seen this need for both sun > access manager and CAS both of which follow the same no doubt > "solid" security principles. Customers dictate certain things that > the developer cannot control such as "we want this legacy > application login screen to look like it always did but now we want > to use CAS". > > Also JSF has also introduced a complexity that lots of forum posting > are having to deal with. People want to utilize rich JSF components > on their login page for whatever reason. What they want is a secure > way to implement this. The lack of a solution forces people to seek > insecure work arounds or at least to compromise the ideal which > appears to dictate minimizing attack vectors by compromising > functionality. > > > > -----Original Message----- > From: Russ Tokuyama <[email protected]> > Sent: Wednesday, January 21, 2009 12:49 PM > To: Yale CAS mailing list <[email protected]> > Subject: RE: CAS without CAS login page using restful api and > modifiedlogin-webflow.xml > > Hi, > > Why is there such a great need to have each site "own" the login page > and control the entry of the user's credentials? Instead of having a > login box on a site's front page, why not simply put a link to "login > securely"? This should keep the site's front page looking the same > while handing over the login dance to CAS. This yields the least > amount > of complication and work to use CAS for SSO. Why not avoid > duplication > of effort, piling on extra complexity, weakening security, and making > thing more brittle? > > Hope this helps, > Russ > > > On Wed, 21 Jan 2009, Keith Garry Boyce 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 >> 2) I also saw something about telling cas which login page to >> draw. It says wind goes this route but again no example. >> 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 >> 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. >> >> -----Original Message----- >> From: Scott Battaglia <[email protected]> >> Sent: Tuesday, January 20, 2009 9:33 PM >> To: Yale CAS mailing list <[email protected]> >> 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 > > [The entire original message is not included] > _______________________________________________ > 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
