Thanks for the reply. What we might consider is a strip-down version of very simple authentication API when CAS is down, app will call it, just so customers can still get some work done. We will not support SSO with that strip-down version. There is no write operation on this API, either, just validating credential, so that some users can get the most basic work done in the application, even when CAS is down.
One option is to build a separate service that validates user credential (like CAS REST API does, but does not use CAS infrastructure at all), and let each application to call when CAS is unavailable. Having said that, there is additional work on the App side to do this, very little CAS work. Well, if the app. wants to do it, I cannot force them not to. Question, what is the danger of returning encrypted password as an attribute in /serviceValidate call to the app.? Yan On Wednesday, August 21, 2019 at 2:39:54 AM UTC-4, jm wrote: > > In this case, I suggest you to use another authentication method rather > than still rely on CAS protocol. I was asked to design a plan B for this > incident the other day, but the plan is still not ready until now. > > It is hard to make a balance between user experience and security.In my > opinion, plan B should be some kind of challenge authentication. When CAS > is down, and you happened to found it was down when you try to authenticate > user, you just show a challenge authentication page to user(or just a > username/password form). > > It is easy to do so in a normal website, but my case is most of our client > are SPA. In classic web application, we can provide a single SDK (ie. a > filter for Java Spring applications) to make it easier for website > developers to make use of both CAS and chanllenge authentication. But in > SPA scenario, we have to care about both front-end and backend, which is > difficult. > > Or you just build another service, which mocks CAS protocol APIs, and when > CAS server is down, just turn to the mock server, but I doubt it can ensure > security or not. > > 在 2019年8月21日星期三 UTC+8上午4:51:40，Yan Zhou写道： >> >> Hello, >> >> Our organization wants to make sure customers can still use their apps, >> in the event that CAS is down or unavailable (even though we have HA, etc.). >> >> The idea is to have CAS return password in encrypted format to some apps. >> that is critical. When CAS is down, the app. can authenticate using >> encrypted password themselves. SSO does not need to work during that time. >> >> That smells bad, but, I know technically this can be easily done and that >> is what we have been asked to do. >> >> What do you suggest? >> >> Yan >> > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/aef7bcd1-acfd-4971-99eb-ed235c922349%40apereo.org.
