For an existing working app, I want to provide a secondary AuthenticationProvider, probably with a DaoAuthenticationProvider. Let's say it's for authenticating a "back up" password, or a prior password that was changed due to strict password policies and the user forgot the new password. ;-)
For proof of concept, what would the implementation look like for this secondaryAuthenticationProvider that will always authenticate the user regardless of the incoming credentials? (something that returns an authenticated Authentication object)
Which one of the MANY org.springframework.security.providers & subpackage classes and methods should I look at?
Example config:
<bean id="authenticationManager" class="org.springframework.security.providers.ProviderManager">
<property name="providers">
<list>
<ref local="daoAuthenticationProvider"/>
<ref local="secondaryAuthenticationProvider"/> <!-- new AuthProv -->
<ref local="rememberMeAuthenticationProvider"/>
</list>
</property>
</bean>
If you have only one alternative password, you can declare a second DaoAuthenticationProvider backed by a special UserDetailsService, which will produce UserDetails with that alternative password.
Otherwise, you can create a custom AuthenticationProvider. Credentials check in DaoAuthenticationProvider occurs in additionalAuthenticationChecks(), so if you want to change that logic you can create a subclass of DaoAuthenticationProvider and override this method with your implementation.
For example, if you want to authenticate the user regardless of its credentials, you can override this method with an empty implementation.
Sounds to me like you should just create your own UserDetailsService that has this behavior - that would be by far the easiest way to do it.
Related
Our application used to have only one possibility to log in: username and password. Once a new user logged into the application, their session would appear in Spring Security's SessionRegistry.
Now I'm implementing SAML support with the help of Spring SAML. I oriented the setup heavily towards the sample application's configuration. It all works fine. However I noticed that users that log in via SAML don't get their session added to the SessionRegistry.
The usual context file for form based authentication contains the following:
<session-management
invalid-session-url="/login"
session-fixation-protection="newSession"
session-authentication-error-url="/login?invalid_session=1">
<concurrency-control
max-sessions="1"
error-if-maximum-exceeded="false"
session-registry-alias="springSessionRegistry"/>
</session-management>
In my http element for the SAML configuration I added the same. This created a new SessionRegistry but it did not contain anything. I also tried
<concurrency-control session-registry-ref="springSessionRegistry"/>
but this did not contain any SAML authenticated sessions either.
So how can I access SAML sessions?
The problem is that bean definition parsers of Spring Security only automatically link beans created based on the session-management and concurrency-control to the authentication processors included in core Spring Security modules. This means, that SAMLProcessingFilter.setSessionAuthenticationStrategy() isn't called.
You should be able to get it working by declaring the samlWebSSOProcessingFilter bean in the following way (which refers to the concurrency bean automatically created by the concurrency-control element):
<bean id="samlWebSSOProcessingFilter" class="org.springframework.security.saml.SAMLProcessingFilter">
<property name="authenticationManager" ref="authenticationManager"/>
<property name="authenticationSuccessHandler" ref="successRedirectHandler"/>
<property name="authenticationFailureHandler" ref="failureRedirectHandler"/>
<property name="sessionAuthenticationStrategy" ref="org.springframework.security.web.authentication.session.ConcurrentSessionControlStrategy#0"/>
</bean>
As I said in my comment of Vladimir's answer, my problem was that I was adding only a ConcurrentSessionControlAuthenticationStrategy to the samlWebSSOProcessingFilter, and because of that, the new logged users were not registered in the SessionRegistry of Spring Security.
To fix that, I created a CompositeSessionAuthenticationStrategy like this:
#Bean
public SAMLProcessingFilter samlWebSSOProcessingFilter() throws Exception {
SAMLProcessingFilter samlWebSSOProcessingFilter = new SAMLProcessingFilter();
samlWebSSOProcessingFilter.setAuthenticationManager(authenticationManager());
samlWebSSOProcessingFilter.setAuthenticationSuccessHandler(customAuthenticationSuccessHandler);
samlWebSSOProcessingFilter.setAuthenticationFailureHandler(authenticationFailureHandler());
samlWebSSOProcessingFilter.setSessionAuthenticationStrategy(authStrategy());
return samlWebSSOProcessingFilter;
}
/**
* #return the strategy for the SAML authentication: ConcurrentSessionControl (max 1 session per user)
* + RegisterSessionAuthStrat (otherwise, the session of the users are not tracked when they authenticate with SAML)
*
* #author Cyril Gambis
* #date 27 juil. 2020
*/
private CompositeSessionAuthenticationStrategy authStrategy() {
List<SessionAuthenticationStrategy> strategies = new ArrayList<>();
ConcurrentSessionControlAuthenticationStrategy concurrentStrategy = new ConcurrentSessionControlAuthenticationStrategy(this.sessionRegistry);
concurrentStrategy.setExceptionIfMaximumExceeded(false);
RegisterSessionAuthenticationStrategy registerStrategy = new RegisterSessionAuthenticationStrategy(this.sessionRegistry);
strategies.add(concurrentStrategy);
strategies.add(registerStrategy);
CompositeSessionAuthenticationStrategy compositeStrategy = new CompositeSessionAuthenticationStrategy(strategies);
return compositeStrategy;
}
Now, the new users are correctly registered.
I've got a MyAppConversionServiceFactoryBean which I'm registering like:
<bean id="conversionService" class="com.MyProject.MyAppConversionServiceFactoryBean">
<property name="messageSource" ref="messageSource"/>
<property name="converters">
<set>
<bean class="com.MyProject.XRepresentationConverter" />
<bean class="com.MyProject.YRepresentationConverter" />
<bean class="com.MyProject.ZRepresentationConverter" />
</set>
</property>
</bean>
I can continue to list every converter we write into this list, but I'd love to be able to configure it such that this isn't necessary and that converters will automatically register themselves somehow with my factory.
Sidebar 1: If that's not possible with a custom factory, is it possible with the default spring one?
Sidebar 2: If neither the first part nor Sidebar 1 is possible, is it possible to #Autowired the conversionService into the converters (so they can easily call one another)? Attempting to #Autowired ConversionService conversionService has previously given me issues due to not being able to wire the conversionService into an object while it's still busy creating the service.
Note: We're using Spring, but not Spring MVC. I have no control over that, so any solutions on that route will be unfortunately unusable. I can change pretty much anything else about the configuration and Java classes, just not the overarching tools.
#Vikdor's comment on the question pointed me in the right direction.
Spring is apparently capable (and no one I asked in person knew this) of gathering collections of beans through the scanning process with #Autowired annotations. Here's what I needed to achieve the same effect I got from the configuration in the post:
applicationContent.xml must have:
<context:component-scan base-package="com.MyProject"/>
<bean id="conversionService" class="com.MyProject.MyAppConversionServiceFactoryBean" />
MyAppConversionServiceFactoryBean.java:
public class MyAppConversionServiceFactoryBean implements
FactoryBean<ConversionService>, InitializingBean {
#Autowired
private Set<BaseConverter> converters;
}
And then all of my converters now have the #Component annotation.
Relevant Docs on #Autowired do briefly mention that it can be used to collect all beans of a type, but I wouldn't have known that it could be done into any collection type without this thread by Grzegorz Oledzki which addresses the generic form of my question, but takes it down a philosophical route.
Combination of corporateId and username is unique for us in the user table.
I know spring provide a mechanism to write custom query for the authentication.
<bean id="authenticationDao"
class="org.acegisecurity.userdetails.jdbc.JdbcDaoImpl">
<property name="dataSource" ref bean="dataSource" />
<property name="usersByUsernameQuery">
<value>
SELECT username,password,enabled
FROM User WHERE username=? and corporateId=?
</value>
</property>
</bean>
But problem here is we have two bind variables in the query instead of one. I am not sure how do I use spring security framework with this db structure.
Primary key of User table is UserId. Is there any to put preprocessor before calling authenticate method by which I can fetch userId by the combination of username and corporateId and then use this SELECT username,password,enabled
FROM User WHERE userid=? query.
Any help would be highly appericated.
I think you need your own authentication provider since you plan on attempting to match against username, password AND corporate id, the userDetailsService returns the object once the authentication is successful.
take a look at this question and answer, I think it will lead you down the right path
Creating a custom authentication with Acegi/Spring Security
If default JdbcDaoImpl doesn't meet your needs, you may implement your own UserDetailsService:
<bean id="authenticationDao"
class="... your implementation class ..." />
I have a Spring-WS service using PayloadRootAnnotationMethodEndpointMapping that has several interceptors:
<bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping">
<property name="interceptors">
<list>
<ref local="loggingInterceptor"/>
<ref local="validatingInterceptor"/>
<ref local="securityInterceptor"/>
</list>
</property>
</bean>
My securityIntercetor is a Wss4jSecurityInterceptor interceptor.
Everything works fine, except that the securityIntercetor is at the #Endpoint level, I want it to be at the #PayloadRoot (operation).
The way I authenticate users is using UsernameToken, then I go against LDAP and get the roles and depending on the role I want to allow/prohibit the user to execute an operation.
I assume there isn't a out of the box solution for this.
So my question is: how in the securityIntercetor can I get what operation is being called so I can check depending on my settings to allow or not the execution of a specific operation.
Or maybe you have other ideas.
Thanks.
There is no standard way of doing this.
What I did is I created another interceptor (and placing him first in the list of interceptor being called), that would save the current operation and then when Spring hits my security interceptor I will get the method from a request scoped bean that was created by my first interceptor.
Typically, when you declare different "<authentication-provider>" for your application (webapp in my case), Spring Security takes care of invoking providers one after another, incase of failure. So, say I have DatabaseAuthenticationProvider and LDAPAuthenticationProvider with DatabaseAuthenticationProvider declared first in the config file, at runtime, DatabaseAuthenticationProvider is invoked first and if authentication fails, LDAPAuthentication is tried. This is cool - However, what I need is a runtime switch.
I would like to have an option of chosing between these two approaches (database based authentication / ldap based authentication) and somehow swith the implementation based on thsi global setting.
How do I do it? Is it even possible with Spring-Security?
I will leave how to inject your own custom authentication provider to the other myriad of examples from Googleland and here on StackOverflow. It looks like it has to do with marking a particular bean with the xml. But hopefully I can fill in some of the other details for you.
So you've defined the class somewhat like above and I'll add more of the details that you'll need for Spring (i.e. merge the stuff from above as well.
public class SwitchingAuthenticationProvider implements AuthenticationProvider
{
....
public List<AuthenticationProvider> getProviders() { return delegateList; }
public void setProviders(List<AuthenticationProvider> providers) {
this.delegateList = providers;
}
....
}
This will allow you to inject a host of providers using spring:
<bean id="customAuthProvider1" class=".....CustomProvider1"> ... </bean>
<bean id="customAuthProvider2" class=".....CustomProvider2"> ... </bean>
...
<bean id="customAuthProviderX" class=".....CustomProviderX"> ... </bean>
<bean id="authenticationProvider" class="....SwitchingAuthenticationProvider">
<security:custom-authentication-provider/>
<!-- using property injection (get/setProviders) in the bean class -->
<property name="providers">
<list>
<ref local="customAuthProvider1"/> <!-- Ref of 1st authenticator -->
<ref local="customAuthProvider2"/> <!-- Ref of 2nd authenticator -->
...
<ref local="customAuthProviderX"/> <!-- and so on for more -->
</list>
</property>
</bean>
In the end how you populate the providers could be any means of getting the delegator a collection of providers. How they map up to which one to use is up to you. The collection could be a named mapped, based on the current state of the delegator. It could be a list of more than one to try. It could be two properties, "get/setPrimary" and "get/setSecondary" for fail-over like functionality. Once you have the delegator injected the possibilities are up to you.
Let me know if this isn't answering your question.
How about writing a delegating AuthenticationProvider that knows how to access your runtime switch and the actual instances of Database/LDAP AuthenticationProvider.
I'm thinking of something like:
public class SwitchingAuthenticationProvider implements AuthenticationProvider
{
private List<AuthenticationProvider> delegateList;
private int selectedProvider;
#Override
public Authentication authenticate(Authentication authentication)
throws AuthenticationException
{
AuthenticationProvider delegateTo = delegateList.get(selectedProvider);
return delegateTo.authenticate(authentication);
}
....
}