In an enterprise java project that uses spring security, what are the ways to keep some private keys secure at the application server such as weblogic?
If you store the credentials in a property file.
You could change the permission on the configuration files after they have been deployed.
For example you can give readonly access to the application server user, such that nobody else can read the credentials.
Related
I made a new Spring Boot project using the Spring Initializr. I'm building an On-premise backend so what I'm trying to achieve is that when the user opens the jar executable and the server starts, he should be able to configure the database connection by going to localhost:8080/ in his web browser. Basically the index.html will have a form with 4 fields for IP Address, Database Name, UserName and Password. When the form is submitted spring will try to connect to the database with the provided information.
I have all my entities, repositories and controllers but currently the only way i can connect to a database is with the application.properties file, but since the user wont have access to the source, there should be a way for him to configure his database.
Thanks for your time!
I would suggest to use the Spring cloud Config server to store database related properties which is capable of picking up configuration at run time. Although it is typically configured with a Git repository, you can store them locally as pointed out in this thread.
So I've been researching on how to connect to postgres safely using a BasicDataSource from Apache, a Tomcat webserver, and a spring properties file in a Spring App(application.properties/application.yml).
Some suggests to encrypt the property file, and then in runtime decrypt it, but I'm not convinced on how that is safe since someone can use the same decryption to decrypt the password from the properties file
Another suggests to use SSL to connect without a password, which I can't find a clear example on how to actually do this, especially when incorporating JDBC through spring Jdbc and BasicDatasource.
Another suggests to store an encrpyted password that can't be decrypted from the application server, but can be from the postgres server and thus it's safe.
The last suggestion is encryption with a secret as an Environment Variable which is used in the encryption process and decryption process, but isn't that also just as bad since the hacker can see the environment variables if he/she logged in.
I am unsure of how to accomplish a secure connection to postgres with tomcat that is hosting a Spring Boot Web application(packaged to WAR) and would like to request someone's advice or even better, instructions on how they set it up.
we am trying to use vault to keep database credentials and using token in by spring boot application to fetch secrets. Credentials are kept at secret back-end at vault. Connection with application and vault is secure to TLS. This kind of secret distribution is still vulnerable and depends on the developers maturity. Once application has the access to secrets it can be logged in the files. Unlike traditional JEE application, data source is looked up in resource jndi and application never now the database credential. resource setup was done by operations team and access to credentials were limited. Application never has the credential visibility.
Is my understanding correct, if that so how we can make secrets more secure in spring boot application or is this the trade off we have to compromise with.
Very Good Question.
As I think secrets can be logged in the files. As we are getting from vault.
We have to compromise on this. Its same as any secure information (eg. customer data) regarding application can also be logged in the files.
It should be taken care by developer and reviewer.
I am using WebSphere v8.5 and in the administration console, and the Security Settings in the Data Sources section allow me to set my mapping-configuration alias to either ClientContainer or WSLogin. What is the difference between these two settings?
I am able to connect and my project appears to work regardless of which setting I choose. Can someone please explain when is one setting chosen over the other?
Each one in the list is a Java Authentication and Authorization Service (JAAS) configuration, which in turn contains an IBM-implementation of the JAAS Login Module.
According to the reference page, Login configuration for Java Authentication and Authorization Service:
The WSLogin module defines a login configuration and the LoginModule implementation that can be used by applications in general.
The ClientContainer module defines a login configuration and the LoginModule implementation that is similar to the WSLogin module, but enforces the requirements of the WebSphere Application Server client container.
The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere Application Server user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system (EIS).
So for general use, you can use the WSLogin module. When you use a Java EE client, use the ClientContainer module. And when using Java 2 Connectors, use the DefaultPrincipalMapping module.
Check this link for a bit more information Configuration entry settings for Java Authentication and Authorization Service
In general, for any server resources like Datasources, queue connection factories etc, you should use DefaultPrincipalMapping.
ClientContainer alias is more dedicated to external applications running in the client container that will connect to WAS, and WSLogin is more appropriate for apps running on the server that would like to customize authentication process.
we are providing facility to customer to configure ldap server runtime. But when i modify provider server url used in constructor of context source, the application crashes. Is there any way to change ldap server url at runtime? for LdapAuthenticationProvider.
If this is a case where you are changing the provider because one may be down for some reason, you should set up multiple authentication providers (security:authentication-provider) in your spring-security config file. Spring-security will start at the top of the list & keep trying until it finds one that works. That way you can leave this setup & not have a need to redeploy your code.