CAS return password in encrypted format so that App can still work when CAS is unavailable?

[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

[Richard Frovarp]

It's not necessarily easily done. Not sure what CAS can do, but this means that all of your applications have to be setup to use CAS AND use local accounts. Maybe they already are, but they are also going to have to have a custom CAS integration to pull this off likely. Then you have the problem of what happens if those credentials get compromised. Each of those applications are going to have a cached copied of the credentials that an attacker could use. So each of those applications would need a method to flush those credentials under some sort of circumstance. Likely this is already done, but each of those applications would need a method of removing accounts once the person is no longer with you and shouldn't have access. Then you'd also need some sort of fail over method so that people that are used to going through CAS fail over to the normal method? Finally, you can very easily put MFA into the workflow of CAS, but if each application is going to do its own authentication, they would need to do their own MFA integration as well.

So there is a good deal of work that needs to go into each of the applications to maintain usability and security. Part of the beauty of CAS is that all of the above is just done.

--
- 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 cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ebccddb0-b9da-454d-a28f-6693e5a0cc19%40apereo.org.

[Ray Bon]

Yan,

I assume when you say 'CAS is down', you mean that your authentication backend is unavailable, otherwise CAS would not be able to return the password.

There is clearpass, https://apereo.github.io/cas/6.0.x/integration/ClearPass.html, with all its dangers.

It has to be enabled on a per service basis and needs the service's public key.

I think that clearpass bypasses the authentication backend. You would have to manipulate the login flow to only use clearpass if your authentication backend was unavailable.

Your client app will need to be configured/customized for both CAS protocol and clearpass login.

Ray

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

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.

[jm]

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写道：

[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

[Ray Bon]

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

-- 

[jm]

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写道：