thanks ------------------ Original ------------------ From: "Dmitriy Kopylenko"<[email protected]>; Date: Wed, Jul 1, 2015 05:50 PM To: "cas-user"<[email protected]>;
Subject: Re: [cas-user] Embedding username info in Service ticket And one last thing - here's a good article to read which gives a good overview of token-based authentication for REST-based architectures (using JWT in this instance): https://stormpath.com/blog/token-auth-spa/ Cheers, D. Sent from my iPhone On Jun 30, 2015, at 23:16, David Langenberg <[email protected]> wrote: OAuth won't help you much more as you'll still have to do the validation of the access token for every API call with your provider. OpenIDConnect is built on OAuth, so same issue there, granted they do have front-channel flows that will provide you with the ID Token in a single step. That *might* solve your problem or not depending on the value of the aud field in the ID token. Bottom line, you're not going to get away from having to do some kind of validation or build/deploy a robust authentication platform no matter what protocol you choose. Dave On Tue, Jun 30, 2015 at 9:06 PM, Ajay Madhavan <[email protected]> wrote: The issue here is I cannot just validate once. My eco system is rest based and we cannot rely on the session as the service could be multi-instance. So I possibly could end up with a large number of validations..I can look into oauth or open id. Thanks for all the replies. Looks like there is no way to do the user-embedding on the service ticket. Ajay On Tue, Jun 30, 2015 at 1:40 PM, Mailvaganam, Hari <[email protected]> wrote: If managing API ACL - perhaps OAuth/Open ID Connect? Or as another poster replied, manage via session, upon initial CAS validate. Averaging 300K CAS validations/day at term time - no performance issues with 5 load balanced VMs. From: Ajay Madhavan [[email protected]] Sent: Monday, June 29, 2015 15:10 To: [email protected] Subject: Re: [cas-user] Embedding username info in Service ticket 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 -- David LangenbergIdentity & Access Management Architect The University of Chicago -- 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
