For all the folks asking for Spring Security Architecture Slides here you go... github.com/jgrandja/presentations/blob/master/SpringIO-Barcelona2017-JoeGrandja.pdf
This is an excellent presentation. Gives a good understanding of spring security basics. Video has an issue though. Its very difficult to read the slides on the tv as its rendered pretty much white blob on small screen devices (phones). Would you be able to share the slides ?
I awaited you to show us the big picture first: the web-app without security, what's happening when an http request comes in. After that, just by adding the spring-security dependecie the "magic" is security begins. The one important filter that welcomes the request and how the security process involves. I must admit that I have just seen the first 11 minutes.
Only after the video I understand how Spring Security works. However I still don't understand how Spring Security remembers the Authenticated User. Because after the request is done SecurityContextHolder clears the Authentication from the ThreadLocal. So what happens on next request from user? How SecurityContext know that the request come from the same user?
I found an answer in the Spring Security Reference documentation at 9.4.4 Storing the SecurityContext between requests. Depending on the type of application, there may need to be a strategy in place to store the security context between user operations. In a typical web application, a user logs in once and is subsequently identified by their session Id. The server caches the principal information for the duration session. In Spring Security, the responsibility for storing the SecurityContext between requests falls to the SecurityContextPersistenceFilter, which by default stores the context as an HttpSession attribute between HTTP requests. It restores the context to the SecurityContextHolder for each request and, crucially, clears the SecurityContextHolder when the request completes. You shouldn’t interact directly with the HttpSession for security purposes. There is simply no justification for doing so - always use the SecurityContextHolder instead.
Spring Security definitely sucks because: 1) a very awful design decisions 2) overengineered concepts for simple things, for example http.addHeaderWriter(new DelegatingRequestMatcherHeaderWriter(new AntPathRequestMatcher("/login"), new XFrameOptionsHeaderWriter(new WhiteListedAllowFromStrategy(Arrays.asList("www.facebook.com", "www.google.com"))))) 3) expressions in annotations like @AuthenticationPrincipal(expression = "@jpaEntityManager.merge(#this)") 4) SecurityContext.getInstance() static method to retrieve security context while using DI-container at the same time 5) SecurityContextHolder sucks 6) horrible code
