Yan, The most obvious reason for not returning the password is the loss of security. Once the password is released, you lose control. You have to trust that the client app will protect the password while it is in the user's session (encrypted or not) and that it is stored in a safe manner. (I would think that the client app would have its own credential store because if CAS cannot access its credential store, how would the client app?) What happens when the user changes password? They either have to update the password in _all_ apps (how do they know which ones) or you have to build some mechanism to do the update (messy, error prone, and yet another vector for password leakage). On top of all this, every application that stores the password is a potential target for crackers. One app gets compromised, all apps are compromised.
We have a few apps that are not part of SSO, such as our build/deploy, so that we can deploy CAS if it has failed. But they all use the same authentication backend. My push back would be; spend the effort ensuring CAS environment is stable, you have a good rollback system in place for failed deploys, you have rigorous testing for changes/updates, co-locate CAS. Ray On Wed, 2019-08-21 at 06:42 -0700, Yan Zhou wrote: 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 -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | [email protected]<mailto:[email protected]> I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations. -- - 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/bada272ce1dd5116cd0d6f9be13d4907df91bf8d.camel%40uvic.ca.
