Yan, It is danger indeed.
In a CAS protocol, it's a first premise that all service trusts one CAS authentication service. According to my understanding, "credential" you memtioned above, is what you need to log in to CAS service. If those credential is leaked, the attacker will be able to log in to CAS service via those leaked credentials, that is, the attacker is able to log in to all other services, which causes really serious security problem. What's more, once you let credential go to services, you will never know whether it will appear in log or database in plaintext or not. Please keep password properly. James 在 2019年8月21日星期三 UTC+8下午9:42:59，Yan Zhou写道： > > > 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/437f3218-7044-4562-9f8d-95b0b8948159%40apereo.org.
