Exactly. To give you some perspective, the CAS service at Lafayette College never broke 500 authentications in a given *hour* in the last 24 hours.
Thanks, Carl On Jun 29, 2015 6:39 PM, "Andrew Morgan" <[email protected]> wrote: > Something to consider - CAS is an authentication service not a session > manager. CAS will only generate a service ticket when the client's > browser visits the CAS login page and authenticates (possibly > automatically using their existing CAS session). > > Once your application has validated the service ticket, it should > establish it's own session management for that client. Don't redirect > back to CAS every time the client accesses your website/service. > > 1000 authentications per second would be a lot! But you don't want to > CAS-authenticate the user for each API call. Authenticate once, establish > a session (cookie, token, whatever), and validate the session from then > on. > > Andy > > On Mon, 29 Jun 2015, Ajay Madhavan wrote: > > > Hi Carl, > > > > I do have a distributed system where I have multiple services. Imaging > each > > service to be a host by itself. I use cas for authenticating access to > all > > services. > > > > I am expecting api scale to increase enormously over close to say 1000 > api > > per second or so. > > > > I was trying to understand if I could avoid network calls if each of > these > > services were inside a host by themselves. I do understand the CAS > > protocol, just wanted to see if there was a secure way of scaling > > horizontally. > > > > > > Regards > > Ajay > > > > On Mon, Jun 29, 2015 at 1:33 PM, Waldbieser, Carl < > [email protected]> > > wrote: > > > >> > >> Service ticket validation is more or less integral to how CAS works. > >> Maybe if you could explain a bit more in depth what you are trying to > >> accomplish, it might make more sense to the members of the community, > and > >> you could receive better advice. > >> > >> Also, why do you believe there would be some kind of bottleneck > validating > >> service tickets? What kind of volume have you measured or are you > >> expecting in terms of validations per unit of time? > >> > >> Thanks, > >> Carl Waldbieser > >> ITS Systems Programmer > >> Lafayette College > >> > >> ----- Original Message ----- > >> From: "Ajay Madhavan" <[email protected]> > >> To: [email protected] > >> Sent: Monday, June 29, 2015 4:20:49 PM > >> Subject: Re: [cas-user] Embedding username info in Service ticket > >> > >> I do have a secure mechanism to encrypt my service ticket with the > public > >> key and then decrypt it later using the private-key. > >> > >> Also there are multiple webapps which are being protected by the CAS > >> service and I dont want the service validate to be a bottle neck for > each > >> of those webapps. I know service ticket generation does do that. But I > want > >> to see if I can skip service validation at least. > >> > >> Thanks > >> Ajay > >> > >> > >> > >> On Mon, Jun 29, 2015 at 1:04 PM, Dmitriy Kopylenko < > [email protected]> > >> wrote: > >> > >>> I second what Andy says, and just want to add that service ticket > >>> validation is the necessary step in a secure CAS protocol, and the > simple > >>> answer is - “no, you cannot skip the ST validation step”. > >>> > >>> Best, > >>> Dmitriy. > >>> > >>>> On Jun 29, 2015, at 3:55 PM, Andrew Morgan <[email protected]> wrote: > >>>> > >>>> On Mon, 29 Jun 2015, Ajay Madhavan wrote: > >>>> > >>>>> I want to skip service validation. I want to distribute the > validation > >>>>> among all my webapps where i can obtain the username from the service > >>>>> ticket. > >>>>> > >>>>> I still want to use CAS for service ticket generation. > >>>> > >>>> If you don't validate the ST over a back-channel connection, then how > >> do > >>> you prevent someone from spoofing the username? An attacker could put > >>> whatever they want in the ST value to become any other user. > >>>> > >>>> Validating the ST is a necessary step for security. > >>>> > >>>> I don't understand what you mean by "distribute the validation among > >> all > >>> my webapps". > >>>> > >>>> Andy > >>>> > >>>> -- > >>>> 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 > >>> > >>> > >> > >> -- > >> 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 > >> > >> > > > > -- > > 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 > -- 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
