The new Certification Class of Learn Spring Security is out:


1. Overview

In this quick tutorial, we’re going to take a look at how to define multiple entry points in a Spring Security application.

This mainly entails defining multiple http blocks in an XML configuration file or multiple HttpSecurity instances by extending the WebSecurityConfigurerAdapter class multiple times.

2. Maven Dependencies

For development, we will need the following dependencies:


The latest versions of spring-boot-starter-security, spring-boot-starter-thymeleaf, spring-boot-starter-test, spring-security-test can be downloaded from Maven Central.

3. Multiple Entry Points

3.1. Multiple Entry Points with Multiple HTTP Elements

Let’s define the main configuration class that will hold a user source:

public class MultipleEntryPointsSecurityConfig {

    public UserDetailsService userDetailsService() throws Exception {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        return manager;

Now, let’s look at how we can define multiple entry points in our security config.

We’re going to use an example driven by Basic Authentication here, and we’re going to make good use of the fact that Spring Security supports the definition of multiple HTTP elements in our configurations.

When using Java configuration, the way to define multiple security realms is to have multiple @Configuration classes that extend the WebSecurityConfigurerAdapter base class – each with its own security configuration. These classes can be static and placed inside the main config.

The main motivation for having multiple entry points in one application is if there are different types of users that can access different portions of the application.

Let’s define a configuration with three entry points, each with different permissions and authentication modes:

  • one for administrative users using HTTP Basic Authentication
  • one for regular users that use form authentication
  • and one for guest users that do not require authentication

The entry point defined for administrative users secures URLs of the form /admin/** to only allow users with a role of ADMIN and requires HTTP Basic Authentication with an entry point of type BasicAuthenticationEntryPoint that is set using the authenticationEntryPoint() method:

public static class App1ConfigurationAdapter extends WebSecurityConfigurerAdapter {

    protected void configure(HttpSecurity http) throws Exception {

    public AuthenticationEntryPoint authenticationEntryPoint(){
        BasicAuthenticationEntryPoint entryPoint = 
          new BasicAuthenticationEntryPoint();
        entryPoint.setRealmName("admin realm");
        return entryPoint;

The @Order annotation on each static class indicates the order in which the configurations will be considered to find one that matches the requested URL. The order value for each class must be unique.

The bean of type BasicAuthenticationEntryPoint requires the property realName be set.

3.2. Multiple Entry Points, Same HTTP Element

Next, let’s define the configuration for URLs of the form /user/** that can be accessed by regular users with a USER role using form authentication:

public static class App2ConfigurationAdapter extends WebSecurityConfigurerAdapter {

    protected void configure(HttpSecurity http) throws Exception {
            // formLogin configuration
              new AntPathRequestMatcher("/user/private/**"))
              new AntPathRequestMatcher("/user/general/**"));

As we can see, another way of defining entry points, besides the authenticationEntryPoint() method, is to use the defaultAuthenticationEntryPointFor() method. This can define multiple entry points that match different conditions based on a RequestMatcher object.

The RequestMatcher interface has implementations based on different types of conditions, such as matching path, media type or regexp. In our example, we have used the AntPathRequestMatch to set two different entry points for URLs of the forms /user/private/** and /user/general/**.

Next, we need to define the entry points beans in the same static configuration class:

public AuthenticationEntryPoint loginUrlauthenticationEntryPoint(){
    return new LoginUrlAuthenticationEntryPoint("/userLogin");
public AuthenticationEntryPoint loginUrlauthenticationEntryPointWithWarning(){
    return new LoginUrlAuthenticationEntryPoint("/userLoginWithWarning");

The main point here is how to set up these multiple entry points – not necessarily the implementation details of each one.

In this case, the entry points are both of type LoginUrlAuthenticationEntryPoint, and use different login page URL: /userLogin for a simple login page and /userLoginWithWarning for a login page that also displays a warning when attempting to access the /user/ private URLs.

This configuration will also require defining the /userLogin and /userLoginWithWarning MVC mappings and two pages with a standard login form.

For the form authentication, it’s very important to remember that any URL necessary for the configuration, such as the login processing URL also needs to follow the /user/** format or be otherwise configured to be accessible.

Both of the above configurations will redirect to a /403 URL if a user without the appropriate role attempts to access a protected URL.

Be careful to use unique names for the beans even if they are in different static classes, otherwise one will override the other.

3.3. New HTTP Element, no Entry Point

Finally, let’s define the third configuration for URLs of the form /guest/** that will allow all types of users, including unauthenticated ones:

public static class App3ConfigurationAdapter extends WebSecurityConfigurerAdapter {

    protected void configure(HttpSecurity http) throws Exception {

3.4. XML Configuration

Let’s take a look at the equivalent XML configuration for the three HttpSecurity instances in the previous section.

As expected, this will contain three separate XML <http> blocks.

For the /admin/** URLs the XML configuration will use the entry-point-ref attribute of http-basic element:

<security:http pattern="/admin/**" use-expressions="true" auto-config="true">
    <security:intercept-url pattern="/**" access="hasRole('ROLE_ADMIN')"/>
    <security:http-basic entry-point-ref="authenticationEntryPoint" />

<bean id="authenticationEntryPoint"
     <property name="realmName" value="admin realm" />

Of note here is that if using XML configuration, the roles have to be of the form ROLE_<ROLE_NAME>.

The configuration for the /user/** URLs will have to be broken up into two http blocks in xml because there is no direct equivalent to the defaultAuthenticationEntryPointFor() method.

The configuration for URLs /user/general/** is:

<security:http pattern="/user/general/**" use-expressions="true" auto-config="true"
    <security:intercept-url pattern="/**" access="hasRole('ROLE_USER')" />
    //form-login configuration      

<bean id="loginUrlAuthenticationEntryPoint"
  <constructor-arg name="loginFormUrl" value="/userLogin" />

For the /user/private/** URLs we can define a similar configuration:

<security:http pattern="/user/private/**" use-expressions="true" auto-config="true"
    <security:intercept-url pattern="/**" access="hasRole('ROLE_USER')"/>
    //form-login configuration

<bean id="loginUrlAuthenticationEntryPointWithWarning"
    <constructor-arg name="loginFormUrl" value="/userLoginWithWarning" />

For the /guest/** URLs we will have the http element:

<security:http pattern="/**" use-expressions="true" auto-config="true">
    <security:intercept-url pattern="/guest/**" access="permitAll()"/>  

Also important here is that at least one XML <http> block must match the /** pattern.

4. Accessing Protected URLs

4.1. MVC Configuration

Let’s create request mappings that match the URL patterns we have secured:

public class PagesController {

    public String getAdminPage() {
        return "multipleHttpElems/myAdminPage";

    public String getUserPage() {
        return "multipleHttpElems/myUserPage";

    public String getPrivateUserPage() {
        return "multipleHttpElems/myPrivateUserPage"; 

    public String getGuestPage() {
        return "multipleHttpElems/myGuestPage";

    public String getMultipleHttpLinksPage() {
        return "multipleHttpElems/multipleHttpLinks";

The /multipleHttpLinks mapping will return a simple HTML page with links to the protected URLs:

<a th:href="@{/admin/myAdminPage}">Admin page</a>
<a th:href="@{/user/general/myUserPage}">User page</a>
<a th:href="@{/user/private/myPrivateUserPage}">Private user page</a>
<a th:href="@{/guest/myGuestPage}">Guest page</a>

Each of the HTML pages corresponding to the protected URLs will have a simple text and a back link:

Welcome admin!

<a th:href="@{/multipleHttpLinks}" >Back to links</a>

4.2. Initializing the Application

We will run our example as a Spring Boot application, so let’s define a class with the main method:

public class MultipleEntryPointsApplication {
    public static void main(String[] args) {, args);

If we want to use the XML configuration, we also need to add the @ImportResource({“classpath*:spring-security-multiple-entry.xml”}) annotation to our main class.

4.3. Testing the Security Configuration

Let’s set up a JUnit test class that we can use to test our protected URLs:

@SpringBootTest(classes = MultipleEntryPointsApplication.class)
public class MultipleEntryPointsTest {
    private WebApplicationContext wac;

    private FilterChainProxy springSecurityFilterChain;

    private MockMvc mockMvc;

    public void setup() {
        this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac)

Next, let’s test the URLs using the admin user.

When requesting the /admin/adminPage URL without an HTTP Basic Authentication, we should expect to receive an Unauthorized status code, and after adding the authentication the status code should be 200 OK.

If attempting to access the /user/userPage URL with the admin user, we should receive status 302 Forbidden:

public void whenTestAdminCredentials_thenOk() throws Exception {

      .with(httpBasic("admin", "adminPass"))).andExpect(status().isOk());


Let’s create a similar test using the regular user credentials to access the URLs:

public void whenTestUserCredentials_thenOk() throws Exception {



In the second test, we can see that missing the form authentication will result in a status of 302 Found instead of Unauthorized, as Spring Security will redirect to the login form.

Finally, let’s create a test in which we access the /guest/guestPage URL will all three types of authentication and verify we receive a status of 200 OK:

public void givenAnyUser_whenGetGuestPage_thenOk() throws Exception {


      .with(httpBasic("admin", "adminPass")))

5. Conclusion

In this tutorial, we have demonstrated how to configure multiple entry points when using Spring Security.

The complete source code for the examples can be found over on GitHub. To run the application, uncomment the MultipleEntryPointsApplication start-class tag in the pom.xml and run the command mvn spring-boot:run, then accesses the /multipleHttpLinks URL

Note that it is not possible to log out when using HTTP Basic Authentication, so you will have to close and reopen the browser to remove this authentication.

To run the JUnit test, use the defined Maven profile entryPoints with the following command:

mvn clean install -PentryPoints

Go deeper into Spring Security with the course:


  • Rahul

    I have a web application which I build using spring boot, front end is react js
    front end consuming rest api exposed through spring boot which are stateless.
    The problem, I am facing is I have to implement spring security for authentication.
    What I have done so far,
    1.) extend WebSecurityConfigurerAdapter
    2.) implement UserDetailsService, as we have access to username and password as it is stored in our db.

    In configure(HttpSecurity http) method I have done java config for
    formlogin and custom form, also for successurl and failureurl.

    so, Now, when I go to localhost:8080, then it redirects to custom
    login page and also redirects to succesUrl configured.Till here
    everthing is fine, but when if I again click some link on home page it
    goes to back to fetch data but again it redirects to
    authentication page, reason which I think is due to configuration

    Can you please show some light how I can still maintain/check the already authenticated user without using session.

    • Hey Rahul,
      That’s an interesting question, but it’s unfortunately going to be difficult to answer without looking at the code. The way to go here would be a PR on Github (one the repo of this article), or at least an example project on Github – and I’d be happy to have a look.
      Hope that helps. Cheers,