I am working on an old application which has huge code from legacy.
Application is based on Spring 2.0 and using Acegi plugin for security. The Tomcat server is successfully configured on HTTPS port.
Now I need to redirect the login over HTTPS. I tries setting following in my template_spring_config.xml
<bean id="authenticationEntryPoint" class="src.auth.acegi.myAuthenticationProcessingFilterEntryPoint">
<property name="loginFormUrl" value="http://#domain.name#/welcome"/>
<property name="forceHttps" value="true"/>
</bean>
Help found so far indicates that this much should be enough to redirect on HTTPS. But this is not working at all and my Request for login remains on HTTP.
I cannot switch to Spring-Security and higher Spring versions due to time constraint.
Please help if you know what else I need to do.
It's difficult to say for sure since you are using a custom entry point implementation (which may behave differently), but you are using an absolute URL, which will probably override the default logic for building the redirect. Try using https:// rather than http:// for your login URL scheme.
Note that you really shouldn't be using Acegi since development stopped on it a long time ago. It contains most (possibly all) of the vulnerabilities that have subsequently been patched in Spring Security. The same goes for Spring itself.
Related
Spring 3.2.6
There might be an easy solution for this that I've missed, but I've been scouring the boards for the last couple days, tried a few things and so far nothing - so I thought I'd consult the experts.
My app:
I have 5 JaxWsPortProxyFactoryBean beans configured in my applicationContext.xml that connect to and consume various web services. Everything works fine, very nice!
Problem:
When my app starts there may be 1 or more web services that are either OFF or not accessible. This is fine as my app can run without them; however, is there a way to continue processing other beans in the context after receiving a TimeoutException (or any Exception due to connectivity with the WS)?
I was hoping for a property in JaxWsPortProxyFactoryBean like continueOnError or something similar.
Hope this makes sense.
You can disable the lookup/check of the web service at startup by setting the lookupServiceOnStartup property to false.
<bean id="yourService" class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean">
<property name="lookupServiceOnStartup" value="false" />
// Other properties
</bean>
Advantage your application starts up a bit faster, drawback the first call to the web service might take a little longer.
You can check the javadoc for more information, the lookupServiceOnStartup property is defined on the JaxWsPortClientInterceptor.
Possible solution is to use setLookupServiceOnStartup and set it to false.
http://static.javadoc.io/org.springframework/spring-web/3.2.6.RELEASE/index.html?org/springframework/remoting/jaxws/JaxWsPortClientInterceptor.html
I've implemented SSO using Spring Security SAML. Here is what currently working for me:
When I try to access any resource at SP, I'm redirected to my IdP(idp.ssocircle.com in my case) if I'm not logged in already. After successful authentication at IDP, I'm redirected back to SP and authorize the incoming SAML response and create a session for the respective user. Everything is cool till here!
But when I log out from my IDP(by clicking logout from idp.ssocircle.com externally), I shouldn't be able to access my SP which is not happening in my case.
Now what I'm thinking to do is may be write a new filter which checks for a valid session at IDP before processing any request on SP. I've searched a lot but couldn't find any solution to my problem.
Please give inputs on how can I implement this filter or is there any other way of doing this? Any suggestions are appreciated.
Does your IDP support and correctly initialize Single Logout? If so it could be related to this issue, just update to latest Spring SAML version or change property invalidateHttpSession in your logout handler to true:
<bean id="logoutSessionHandler"
class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler">
<property name="invalidateHttpSession" value="true"/>
</bean>
I've seen many incarnations of this same issue but I think I've tried all the fixes - my usage is quite straightforward.
I had been using Ehcache which also didn't work. So, to rule out Ehcache issues and help point to something more fundamental, I moved to SimpleCacheManager and ConcurrentMapCacheFactoryBean.
Here's my config:
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="parentAppIds"/>
</set>
</property>
</bean>
Here's my method:
#Cacheable(value="parentAppIds", key="accountNumber")
public Long findApplicationId(String accountNsc, String accountNumber) throws EMSException {
....
}
This is a method on an interface, who's implementing class is Spring managed #Service("foo")
I tried using 'p0' as is suggested here but to no avail. I have no compilation problems and no errors in my server logs so I'm confident that I have all that is necessary on my classpath; and that Namespaces are all fine, since I'm using STS for that - so I left out pom.xml and spring Namespace declarations to block noise.
I'm using Spring 3.1; Java 1.5 and Websphere 6.1
The symptom is that the method is being visited with the same parameters repeatedly.
Please help - I'm hungry and refuse to go for lunch until I nail this.
note: I have simplified my #Cacheable declaration my actual one is
#Cacheable(value="parentAppIds", key="#p0.concat('-').concat(#p1)")
Neither work.
Thanks.
** Edit - I've ruled out Websphere as being a problem by creating a test rig with
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(...)
which mimics what is happening. #Cacheable is simply not working. There must be something blindingly obvious that I am missing. (I've had lunch now)
My issue is resolved. Unfortunately I cannot pinpoint exactly where my issue lay. Certainly, all that is required is that which I have mentioned in my question.
TO fix this, I tidied up my Spring configuration a bit and cleared my browser and application server cache and temp directories. I did a full clean install and cache is now working.
It is possible that I was testing with an earlier version which did not include this important line in the application config:
<cache:annotation-driven/>
I had omitted that at the start. Maybe my adding of that was not picked up until now. Otherwise I am stumped. Thanks for your time.
Did you perhaps change
#Cacheable(value="parentAppIds", key="accountNumber")
to
#Cacheable(value="parentAppIds", key="#accountNumber")
as adding the # that removed one error for me while trying to get caching working.
I am hoping that someone will help me out with a really frustrating problem I have.
Currently I am trying to get Spring Security 3.0 Web App to authenticate with an AD LDS instance but I keep getting this error 'Bad Credentials'. Unfortunately I dont have anything more to go on at the moment.
Below is a copy of the Security configuration being used:
<authentication-manager alias="ldapAuthenicationManager">
<ldap-authentication-provider user-dn-pattern="CN={0},OU=Users,O=JLP,C=UK" >
</ldap-authentication-provider> </authentication-manager>
<ldap-server url="ldap://servner ip/o=JLP,c=UK" manager-dn="CN=Manager,O=JLP,C=UK" manager-password="manager" />
I suspect the problem is caused by the <Ldap server> tag and that the manager-dn is not configured correctly. The DN of the Manager is copied directly from AD LDS - have I not provided enough information? Or does the password need to encrypted\hashed?
Has anyone done anything like this with LDS - how did you work around this problem?
Applogies that this is so vague, but this is as much information as I have to go on. Does any one have any suggestions of things to look at or for solutions?
All help is gratefully recieved!
Cheers
Mo
I am not sure if things would be significantly different for LDS but can you try upgrading to spring security 3.1 as it has a specialized Authenticator for AD.
It does not need manager account as it tries to bind using the username/password being authenticated. Also the configuration is minimal (No DN, search pattern, etc to be provided)
<security:authentication-manager>
<security:authentication-provider ref="activeDirectoryAuthenticationProvider"/>
</security:authentication-manager>
<bean id="activeDirectoryAuthenticationProvider"
class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
<constructor-arg value="${activedirectory.domain}" />
<constructor-arg value="${activedirectory.server}" />
<property name="convertSubErrorCodesToExceptions" value="true"/>
</bean>
where domain = example.com (from your example, jlp.uk) and server = ldap://ip
I remember that I came across with the same issue and the solution was to set the value of manager-dn
to manageruser#yourdomain
e.g.
<ldap-server url="ldap://servner ip/o=JLP,c=UK" manager-dn="morrislgn#example.com" manager-password="manager" />
Thanks for your answers they were very helpful.
Also found that the user account you are using for the manager-dn needs to be added to the reader role within LDS to allow it to search.
If you add the user role to the Administrators group you can connect but not search.
Cheers for your help
Slight necromancy here, but for those who stumble across this via Google, the most helpful tool I found regarding configuring my LDAP connection was to install Apache Directory Studio LDAP browser. It was via this tool that I was able to get verbose enough error messages to discover what was wrong with my LDAP configuration, and how to correct it.
I have a Spring Boot & Spring Security application running, which should now get multi tenancy support.
I'd like to keep things as simple as possible. Though I'd like to determine the the database by path variable or request parameter. (the Apache Web Server in front of the Spring Boot app will handle that, i.e. it maps from subdomain to either path variable or request parameter).
Now I need a way to grab the first path variable (or a specific request param) before Spring calls the controller, and of course the value must be stored somewhere, so I can access it when I need to choose the right database.
So either (depending on what's possible / easier)
http://localhost:8080/customer1 (which I'd prefer) or
http://localhost:8080?_customer=customer1
should simply call the #Controller with #RequestMapping("") and the value customer1 should be stored somewhere for that request.
I know that 2. might be simpler, because it will already hit the right #Controller, but I'd prefer 1. somehow.
Thank you!
EDIT:
I just recognized, that HandlerInterceptor doesn't work as expected, because Spring Security always handles the requests first. Though I need an Interceptor that handles it before Spring Security kicks in.
You can make use of org.springframework.web.servlet.HandlerInterceptor. Implement the logic to store the values in request via preHandle method.
Configure it in spring config file as below
<mvc:interceptors>
<bean class="com.blah.interceptor.SomeInterceptor"/>
</mvc:interceptors>
In case requests are to be intercepted based on path, use below config instead
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/customer1" />
<bean class="com.blah.interceptor.SomeInterceptor"/>
</mvc:interceptor>
</mvc:interceptors>