Hi Luigi, 1) CAS scales well.
CAS is lightweight, such that its interaction is at time of login to applications and optionally at the time the single sign-on session ends, and otherwise doesn't do anything. Applications aren't expected to check with CAS on every request; CAS isn't proxying all of an application's pages; etc. CAS is an authentication broker. It provides interactions that introduce a user securely to an application to establish an application-user session that the application is then expected to manage traditionally, without further bothering CAS. So, for CAS load purposes, the question is how many of your millions of users will be logging in all at the same time. Not logged in at the same time. Logging in at the same time. This allows CAS to scale well. More logged in users also linearly increases the amount of ticket state CAS needs to be keeping track of on the server. Ticket state is pretty small, and clustered ticket registry options allow you to abstract this state out of the JVM and into a database or external cluster. 2) Losing CAS server state is low-consequence If your CAS server goes down and you lose the ticket registry state, all users will lose their single sign-on sessions. This doesn't mean that logged in users lose access to the applications they were logged into. They'll have established authenticated sessions with those applications which users will blissfully continue to use, unaware of the CAS server having crashed and burned. However, yes, you can cluster CAS and CAS ticketregistry state such that losing a CAS server doesn't cause a lose in ticket registry state. This will maintain end-user CAS single sign-on sessions and also maintains the viability of valid Proxy Granting Tickets if you're using the n-tier delegated authentication features of CAS. CAS being unavailable is a problem, in that users cannot establish new logged in sessions with CAS-using applications. It's therefore important to keep your CAS server service available or to be able to restore it quickly. Warm spares have served some CAS adopters well. Keeping CAS ticket registry state across a CAS server restart doesn't tend to be very important unless you're using proxy tickets, since without the proxying feature, the consequence of losing this state is merely that users need to present username and password again the next time they try to log into something via CAS. 3) High scale references You might peruse the Jasig CAS website listing of deployments seeing if anything gives you confidence: http://www.jasig.org/cas/deployments And I hope adopters using CAS at scale will chime in on this thread. Kind regards, Andrew On 11/01/2011 01:12 PM, Luigi Gianni wrote: > I've been doing a research about Single Sign On applications to > implement in a few high-scale applications in Brazil, and I've landed > on CAS as the best option. But I still need a few specific > informations, and I can't find it anywhere else. > > 1.How is CAS scalability? The applications I work with may deal with > thousands maybe millions of users. How would CAS handle that? > 2. There is a problem that CAS stores a copy of the tickets in its > server, and if goes down, all users already logged in lose access. Can > we solve that problem through clusters? > 3. Finally, do you have any examples, besides universities, of > high-scale applications that use CAS and how many users they serve? > > Thanks for your time. > > > -- > *Luigi Cenatti Gianni* > Gerente de Finanças > > Fundação CERTI > NEO Empresarial > [email protected] <mailto:[email protected]> > www.certi.org.br <http://www.certi.org.br/> > Fone: +55 48 3239-2041 > Fax: +55 48 3239-2009 > > > Esta mensagem (incluindo arquivos anexos) contém informações > confidenciais, privilegiadas ou protegidas por lei. Ela é dirigida > exclusivamente ao seu destinatário que a empregará nos ditames legais. > Se você não é o destinatário desta mensagem, deve imediatamente > destruí-la e advertir o remetente do erro de envio e a destruição da > mensagem. Qualquer divulgação, utilização, disseminação ou reprodução > (total ou parcial) desta mensagem ou das informações nela contidas é > proibida e sujeitará a sanções criminais a que incorrer, sem prejuízo > de perdas e danos. > > This e-mail (including attached files) contains information that is > confidential, privileged or protected by law. It is intended solely > for the addressee who will use it under the applicable law. If you are > not the intended recipient, you must immediately destroy it and notify > the sender of the delivery error and destruction of this message. Any > disclosure, use, dissemination or reproduction (in full or in part) of > this message or its contents is prohibited and will result in criminal > sanctions, without prejudice to any damages. > > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
