That is included OOTB. You do not need to do anything extra. 

You are to use this:
http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_encryption_and_decryption

I created this issue to explain the above link better from the CAS perspective:
https://github.com/apereo/cas/issues/1907

Keep an eye on that one. Some notes about it will show up in the CAS docs. 

-- 
Misagh

From: David Curry <[email protected]>
Reply: David Curry <[email protected]>
Date: July 20, 2016 at 11:52:30 AM
To: CAS Community <[email protected]>
Cc: [email protected] <[email protected]>
Subject:  Re: [cas-user] Questions about configuration management (CAS 5.0)  

Thanks for the detailed answers; that all makes sense.

The GitHub approach to storing the application.properties file(s) sounds pretty 
neat; especially if we were to ever do some kind of split on-prem/cloud 
deployment (which we have been kicking around but won't be in our first 
iteration).

But what do you do about storing passwords in those files? I see a shortish 
mention of Java Simplified Encryption in the Security Guide... is that how you 
handle it? If so, is that included out of the box, or will I need to include 
something in the Maven overlay? And (of course), is there any guidance about 
how to actually use it?

On Wednesday, July 20, 2016 at 1:31:57 PM UTC-4, Misagh Moayyed wrote:


First, reloading changes. The first paragraph there explains the embedded 
configuration server that notices when the application.properties file gets 
updated and reloads the properties. But then the second paragraph talks about 
an "adopter" needing to submit a request to CAS to refresh its current state to 
make the new properties actually take effect. But it doesn't say whether the 
embedded configuration server is considered an adopter. So here's my first 
point of confusion -- If I edit application.properties, will those changes take 
effect all by themselves just by editing the file? Or do I also need to 
manually visit the server dashboard page and click "Refresh"?
It depends. 

If you are running CAS in embedded mode via the -jar option, any changes you 
make to the externally-defined application.properties file must be refreshed on 
the dashboard. This is a current limitation of the UI; there is a screen that 
shows and lists all your properties, but it doesn’t yet let you edit them right 
there. If it did, it would auto-refresh everything and you wouldn’t have to 
worry about “where is my application.properties” file. This bit of UI 
enhancement will likely not make it to 5 for the GA release and so for the time 
being, you edit the file, and you refresh the config by pressing that button 
(or you send a POST to the relevant endpoint which is what that button does). 
We are working on that missing UI bit to make sure the screen can be edited, 
and that will likely make its way into subsequent patches post the 5 GA 
release. If it does, saving the property/change on the UI will do the refresh. 
One-stop shop. 

If you were running CAS in embedded mode via the native boot plugin, something 
we don’t yet have worked out, there is no refresh needed when you edit settings 
that are under src/main/resources of your configuration/overlay regardless of 
what those settings/files are. That directory is and will be monitored by the 
plugin constantly and resources there will be auto-loaded. This model is best 
suited for development. A refresh is still needed for anything that sits 
outside your “workspace” directory where your local CAS config files are. Same 
story with the UI. 

If you are running CAS in an external container, it’s the same as if you were 
running it with a -jar option. Refresh is needed. 



Next, clustered deployments. I understand that if the Spring Cloud Bus is 
configured, then when one of the servers reloads its properties, it will 
broadcast them out to the other servers on the bus, so that they all get them. 
But here's my next point of confusion -- Let's suppose I have 3 servers (A, B, 
and C) and change the properties file on A. The Cloud Bus will make sure those 
changes get propagated to the running instances on B and C, but will it also 
update the properties file on those two servers? Or do I need to make sure the 
files are kept in sync through some out-of-band process?
You still need to sync. Changes are not persisted on disk; they are only 
broadcasted and applied to the runtime running instance. Ideally, you are 
keeping track of those settings in a shared repository where you make a change 
in once place and its broadcasted to all nodes. I have tested this throughly 
with that repository being github. It’s amazing how Spring Cloud does it. You 
make a change, you commit and CAS auto-recognizes it and shoots a message to 
all nodes, who then recognize the change and update the running CAS instance 
invisibly. 

If you are not using a shared “repository”, as I said, you do need to sync. 

I have played around with the idea of using something other a properties file 
to keep these changes, specially for the implementation of that UI and 
specially when you don’t want to deal with source control. (Odd, but it 
happens). A lightweight DB table or a MongoDB collection of some sort as an 
option which would then allow you to centralize those settings better (and hey, 
you can write your own UI on top of that if you wanted to). 

HTH.  

And I’ll see about formulating something intelligent for the docs. Thanks for 
the feedback!



Thanks,
--Dave



--
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/2148dba1-c059-4c45-babe-4e6c48144924%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
--
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/1439ec30-708f-43a4-bb43-00932ea64de7%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

-- 
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/etPan.578fca99.400c1487.e819%40unicon.net.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Reply via email to