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.
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.
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.
I have been looking everywhere on how I can implement Spring Security based on a Container Managed Security Model. In my test case, I am using Tomcat and it's corresponding tomcat-users.xml file. The issue is, I cannot get Spring Security to play well (meaning pass authentication over to Tomcat) to let the app server perform the Authentication and have Spring manage the role based security once someone is authenticated. I am using the latest Spring versions, so it's all Java config as I am just not familiar enough with XML based config. I have read many examples that talk about using a PreAuthenticatedAuthenticationProvider but the examples are poor not to mention the Spring documentation is quite confusing IMHO. I even downloaded the sample preauth code from the Spring Security GIT hub but I still cannot see how the example code is tied to the authentication that Tomcat is performing. When I run the Spring sample code for preauth, it doesn't authenticate with any of the users in my tomcat-users XML file as I deployed my code to Tomcat 8. Wondering if anyone has any ideas on where I can look in order to understand how Spring Security and the authentication performed by Tomcat (container managed) happens?
UPDATE:
It appears I had to start from scratch and simply get the authentication to work with a very simply app created in my IDE. Basically I had a folder that was called secure, one folder that was called unsecure and I mapped the paths according to the Servlet 3 spec to secure and unsecure what I needed. I had to use a web.xml in order to contain the security constraints. Once I tested in both Tomcat 7 and 8, where I tried to hit a secure URL, I was challenged to enter an ID and password. Please note you have to define the path to a login page, mine was a simple JSP. I also had to submit to the j_security_check and also make sure to use the j_username and j_password field names. Once I knew I could hit a secure page, I then started introducing the Spring components. This involved Spring Security, Spring Boot etc. The key was in the WebSecurityConfigurerAdapter. Where I normally would have basic auth or form based security enabled, I removed those and instead used the jee() setting based on the same fluent builder API used to configure your security settings. I left all antmatcher settings in the web.xml, so my WebSecurityConfigurerAdapter was very basic. When you are debugging controllers, you can inject the HttpServletRequest directly in the method and that request contains a userPrincipal request value containing things such as the user ID, and roles. Good luck, hope this helps others because it was painfully long for me to figure out such a simple solution.
See the update for a detailed explanation on my solution.
I'm adding Spring security to an internal website. I've been asked to have the authentication be tied to tomcat-users.xml, so that we can cut down on the number of passwords to change/remember.
From what I've been able to Google up, this isn't very straighforward, if at all possible.
Things are working fine, for now, with a user + role hardcoded in springSecurity.xml.
You can treat container security as a pre-authenticated scenario.
There's a sample app in the codebase which uses this approach. It uses explicit bean configuration, but there is also a <jee> namespace element available.
This could be done as a pre-authenticate scenario as Luke indicates but I do not suggest that option. When you are using tomcat xml file you are using MemoryRealm but you could switch to JDBCRealm and have both users (Spring and Tomcat) stored in the database. I suggest this for maintenance, consistency and security. If you change your servlet container you will have to migrate your security users and roles.
https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#MemoryRealm
I need to have web application which actually consist from few separate wars unified into same navigration bar on UI, i need to have all system secured but have authentication only to main web application and after automatic propagation of this security context to sub web applications. I'm using spring security, could someone help me with advice? thanks
This can be achieved by following approach. In Spring, SecurityContext by default is stored in HttpSession. Instead you can configure it to store in some shared repository.
So, configuration should be changed to use your own SecurityContextRepository implementation instead of HttpSessionSecurityContextRepository. Once configured, the security framework will look at the Repository which is available to all your web applications.
The Repository can be either a database or a cached server.
Spring Security stores the login data in the http session. So what I would try is to share the session between the applications.
It seams that this is possible (in Tomcat) by using the Single Sing On attribute.
But be warned, sharing the session between two applications is not without danger. See this Stack Overflow question.