So far we have been quick to setup Spring Security and apply it in our application. But behind that minimal configuration and non-invasive behavior lot has been happening behind the scenes.
It is time to uncover the activities under hood, draw some diagrams to understand the framework and move ahead in style. I will not draw out all the balls from the magic box now. Instead will slowly take out one ball at a time to make it slow and easy to comprehend and assimilate.
Let us go back to the web.xml configuration. You will see that we have configured a DelegatingFilterProxy. This filter is named 'springSecurityFilterChain'. The delegating filter proxy looks for a bean named 'springSecurityFilterChain' in the root Spring web application context. So note that this name is kind of a reserved bean name and should not be used elsewhere. The delegating filter proxy as the name suggests delegates the entire security processing then to the beans declared in the Spring web application context/ or security context. Now the question in your mind is that you never declared a bean with name - 'springSecurityFilterChain' , then from where on earth did the delegating filter proxy get it and the framework started running? Well the 'springSecurityFilterChain' bean is created by the declaration <http>....</http>
There is a lot to learn and understand with this namespace configuration - <http>. So it needs a be enjoyed slowly like a good whisky.
You must have already understood that Spring Security is based on servlet filters. This is what the official documentation says - "Spring Security's web infrastructure is based entirely on standard servlet filters. It doesn't use servlets or any other servlet-based frameworks (such as Spring MVC) internally, so it has no strong links to any particular web technology. It deals in HttpServletRequests and HttpServletResponses and doesn't care whether the requests come from a browser, a web service client, an HttpInvoker or an AJAX application. Spring Security maintains a filter chain internally where each of the filters has a particular responsibility and filters are added or removed from the configuration depending on which services are required. The ordering of the filters is important as there are dependencies between them. "
Just to extract the keywords - irrespective of the source of http request the intercepting filter (configured as a delegating filter proxy in web.xml) hands over the actual security processing to a filter chain configured internally or Spring web application context. The request passes through each of the internal filters and is processed depending on what are the security requirements of the application or what customization has been done. Note you can very well introduce your own filter.Also note that the order of the filter in the filter chain is very important and there may be dependencies between filters in the chain. A filter coming later in the chain may depend on some data produced by filter coming earlier in the chain. I will dig deep into all these and also take indepth look into different filters that are available out of the box and also try to show the use of a custom filter in the chain.
Since we used the new namespace based configuration, the required filters are automatically configured and no bean needs to be explicitly configured. But sometimes fine grained control is required (and these may not be supported in namespace based configuration). In this case it is very well possible to get full control over the filter chain and the filters.
Now I leave you with a big picture of Spring security. In my next post I will to uncover more details about Spring security and its filters. I will blow out that yellow box more in the next post.
It is time to uncover the activities under hood, draw some diagrams to understand the framework and move ahead in style. I will not draw out all the balls from the magic box now. Instead will slowly take out one ball at a time to make it slow and easy to comprehend and assimilate.
Let us go back to the web.xml configuration. You will see that we have configured a DelegatingFilterProxy. This filter is named 'springSecurityFilterChain'. The delegating filter proxy looks for a bean named 'springSecurityFilterChain' in the root Spring web application context. So note that this name is kind of a reserved bean name and should not be used elsewhere. The delegating filter proxy as the name suggests delegates the entire security processing then to the beans declared in the Spring web application context/ or security context. Now the question in your mind is that you never declared a bean with name - 'springSecurityFilterChain' , then from where on earth did the delegating filter proxy get it and the framework started running? Well the 'springSecurityFilterChain' bean is created by the declaration <http>....</http>
There is a lot to learn and understand with this namespace configuration - <http>. So it needs a be enjoyed slowly like a good whisky.
You must have already understood that Spring Security is based on servlet filters. This is what the official documentation says - "Spring Security's web infrastructure is based entirely on standard servlet filters. It doesn't use servlets or any other servlet-based frameworks (such as Spring MVC) internally, so it has no strong links to any particular web technology. It deals in HttpServletRequests and HttpServletResponses and doesn't care whether the requests come from a browser, a web service client, an HttpInvoker or an AJAX application. Spring Security maintains a filter chain internally where each of the filters has a particular responsibility and filters are added or removed from the configuration depending on which services are required. The ordering of the filters is important as there are dependencies between them. "
Just to extract the keywords - irrespective of the source of http request the intercepting filter (configured as a delegating filter proxy in web.xml) hands over the actual security processing to a filter chain configured internally or Spring web application context. The request passes through each of the internal filters and is processed depending on what are the security requirements of the application or what customization has been done. Note you can very well introduce your own filter.Also note that the order of the filter in the filter chain is very important and there may be dependencies between filters in the chain. A filter coming later in the chain may depend on some data produced by filter coming earlier in the chain. I will dig deep into all these and also take indepth look into different filters that are available out of the box and also try to show the use of a custom filter in the chain.
Since we used the new namespace based configuration, the required filters are automatically configured and no bean needs to be explicitly configured. But sometimes fine grained control is required (and these may not be supported in namespace based configuration). In this case it is very well possible to get full control over the filter chain and the filters.
Now I leave you with a big picture of Spring security. In my next post I will to uncover more details about Spring security and its filters. I will blow out that yellow box more in the next post.
Comments
Post a Comment