We at BYU used to have a layout similar to what you are describing for the 
login. We had portions of the page in ssl so that the login form would be via 
ssl but because the whole page wasn't in SSL it was susceptible to injection 
attacks. We didn't want to go to a full ssl page because we like caching and 
all of its benefits. For this reason we opted to going to a secure link that 
went to an all ssl login page that re-routes back to the page that requested 
the login after the login is completed. We had about 30 people of 30k that 
complained on the extra click but most people just took it in stride. Now, 1 
1/2 years later, no one complains and we haven't had anymore successful hack 
attempts, even by our security labs. It was just over a year ago that we 
changed to CAS. There are some people that want to control their login page and 
I can see how it would be nice to be able to set css by url that comes in to 
allow for some of that but we would never consider allowing other people on 
campus to have their own page for our CAS server. We have been burned by that 
kind of thing before with LDAP authentication. Plus single sign on really 
relies on a single CAS authority. Security has to come before design, or even 
usability. The most usable page would be one without security or logins, all 
those extra clicks and the inconvenience of remembering a login and password.


Sherwin Harris
Brigham Young University
Office of Information Technology
[email protected] 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On 
Behalf Of Keith Garry Boyce
Sent: Wednesday, January 21, 2009 12:04 PM
To: Yale CAS mailing list
Subject: RE: CAS without CAS login page using restful api and 
modifiedlogin-webflow.xml

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

Reply via email to