I am using spring security in my project and I do aware that the provided interface UserDetailsService is just like the normal interfaces we wrote, but I want to know is there any special purpose behind that the Spring people provide this interface containing single method?
What I observed that, we pass the Implementation class to the method userDetailsService() of AuthenticationBuilderManager, so we do not need to bother to invoke service explicitly in the controller.
Apart from this is there any other benefits ?
The UserDetailsService interface is used by DaoAuthenticationProvider for retrieving a username, password, and other attributes for authenticating with a username and password. The benefit of having a core interface for that is that users can define their own way to retrieve the UserDetails, and Spring Security just needs a #Bean of that type.
For example:
#Bean
UserDetailsService customUserDetailsService() {
return new FileSystemUserDetailsService();
}
Spring Security does not need to be aware that you are loading users from the OS file system since all it requires is that you provide a #Bean of the UserDetailsService type. This way it simplifies support for new data-access strategies.
There are more details in the Spring Security docs.
Related
Spring Security what is the difference between Authorization Manager and AccessDecisionManager, and how do they interact with each other?
The AuthorizationManager, from Spring Security documentation:
AuthorizationManager supersedes both AccessDecisionManager and AccessDecisionVoter.
Applications that customize an AccessDecisionManager or AccessDecisionVoter are encouraged to change to using AuthorizationManager.
AuthorizationManagers are called by the AuthorizationFilter and are responsible for making final access control decisions.
The deprecated AccessDecisionManager, from Spring Security documentation:
The AccessDecisionManager is called by the AbstractSecurityInterceptor and is responsible for making final access control decisions.
In summary, the AuthorizationManager is a new API that supersedes the AccessDecisionManager. If you are using authorizeHttpRequests instead of authorizeRequest, you are already using the AuthorizationManager API.
I use Spring boot security for my server.
I added new filter that extends from OncePerRequestFilter and (according to many tutorials from the web) after validating the jwt save Authentication object into SecurityContext.
What I don't understand is why do I need to save the Authentication in SecurityContext? after all I validate the jwt from the client in each request and don't need spring's to call isAuthenticated() on Authentication object.
Do I miss something?
Spring Security Authentication basically works by storing it in the SecurityContext. There is a SecurityContextHolder class which stores the SecurityContext and is used to many places where Authentication/Authorization decisions needs to be made by retrieving the Authentication. Even though you have validated the JWT to check the Authentication is success, Spring Security still needs Authentication object to make other decisions for example to evaluate hasRole(), hasAnyRole(), etc.
We are using multiple datasources distributed across regions. Each datasource is meant to handle all data related to all users of the region including security related data such as roles, tokens etc. I can not have all security related information in one datasource.
Does Spring security rest plugin for Grails support this setup? From what I understand it always looks at the default datasource for all authentication related tables and stores all tokens in default datasource alone.
Could someone confirm this? If the plugin supports multiple datasources, how to make it work?
Our environment:
Grails 2.4.4
Spring security rest plugin 1.5.3
Spring security core 2.0-RC4
Postgresql 9.5
Grails supports multiple datasources:
http://docs.grails.org/2.4.4/guide/single.html#multipleDatasources
In order to adjust Spring security core, one relatively easy option, would be to provide an alternative userDetailsService. (method: loadUserByUsername(String username) could be customized to do that)
Which is in use by the DAOAuthenticationProvider to get user's details.
At that point, You would probably need to access more parameters from the request, to determine which datasource to access. So, the request object could be obtained using (for grails 2.x.x):
GrailsWebRequest webUtils = WebUtils.retrieveGrailsWebRequest()
def request = webUtils.getCurrentRequest()
Using Sring Data JPA, Spring Data REST 2.4.2, Spring Security and Spring Boot 1.3.1. I have an Account entity that I want to expose over REST for admin purposes:
#PreAuthorize("hasRole('ROLE_ADMIN')") //exclusive admin access
public interface AccountRepository extends JpaRepository<Account, Long> {}
This works as expected and I can access the REST interface with a proper admin role.
Another requirement I have is to allow non-admin users to register and authenticate over HTTP. For that I've created a custom Controller that exposes register() and login() functionality over /register and /login resources. The issue is that when the registration/login internal logic interacts with the repo above, there is no user security context that can be attached, apart from an anonymous one.
To keep things simple I have created a second repo that is not exported and has no security requirements:
#RepositoryRestResource(exported = false)
public interface AccountRepositoryInternal extends JpaRepository<Account, Long> {}
This repo is then then injected in the said controller.
The issue is that I see inconsistent behaviour with the exported interface. In some runtime environments the interface is exported over REST and in others it is not. Is there a better strategy I could use?
You can add #PreAuthorize at both class and method level, so if you need only some methods do be secured just:
Use only one repo instead of two
Extend Repository instead that JPARepository
Copy and paste (literally, they are just placeholders) all the methods that you need from PagingAndSortingRepository.
Add #PreAuthorize accordingly to your needs to specific methods, not to the class.
Copying and pasting methods among repositories interfaces is what the docs suggests (http://docs.spring.io/spring-data/jpa/docs/1.9.2.RELEASE/reference/html/#repositories.definition-tuning) if you want to have a fine grained control, such as in you case.
I am in the process of converting a legacy application from proprietary technology to a Spring based web app, leaving the backend system as is. The login service is provided by the backend system through a function call that takes in some parameter (username, password plus some others) and provides an output that includes the authroizations for the user and other properties like firstname, lastname etc.
What do I need to do to weave this into Spring 3.0 security module. Looks like I need to provide a custom AuthenticationProvider implementation (is this where I call the backend function?). Do I also need a custom UserDetails and UserDetailsService implementation which needs loadUserByName(String userName)?
Any pointers on good documentation for this? The reference that came with the download is okay, but doesn't help too much in terms of implementing custom security.
You only need to implement a UserDetailService, only when you like to make available some User details that's don't fit in the standard Spring User details class: org.springframework.security.core.userdetails.User you need to implement one for you're selves.
A good example you find here (just replace the hibernate stuff, with what ever you use for communicating with the backend).