This appendix provides a reference to the elements available in the security namespace and information on the underlying beans they create (a knowledge of the individual classes and how they work together is assumed - you can find more information in the project Javadoc and elsewhere in this document). If you haven’t used the namespace before, please read the introductory chapter on namespace configuration, as this is intended as a supplement to the information there. Using a good quality XML editor while editing a configuration based on the schema is recommended as this will provide contextual information on which elements and attributes are available as well as comments explaining their purpose. The namespace is written in RELAX NG Compact format and later converted into an XSD schema. If you are familiar with this format, you may wish to examine the schema file directly.
Enables Spring Security debugging infrastructure. This will provide human-readable (multi-line) debugging information to monitor requests coming into the security filters. This may include sensitive information, such as request parameters or headers, and should only be used in a development environment.
If you use an <http>
element within your application, a FilterChainProxy
bean named "springSecurityFilterChain" is created and the configuration within the element is used to build a filter chain within
FilterChainProxy
. As of Spring Security 3.1, additional http
elements can be used to add extra filter chains [22].
Some core filters are always created in a filter chain and others will be added to the stack depending on the attributes and child elements which are present. The positions of the standard filters are fixed (see
the filter order table in the namespace introduction), removing a common source of errors with previous versions of the framework when users had to configure the filter chain explicitly in the
FilterChainProxy
bean. You can, of course, still do this if you need full control of the configuration.
All filters which require a reference to the AuthenticationManager
will be automatically injected with the internal instance created by the namespace configuration (see the introductory chapter for more on the AuthenticationManager
).
Each <http>
namespace block always creates an SecurityContextPersistenceFilter
, an ExceptionTranslationFilter
and a FilterSecurityInterceptor
. These are fixed and cannot be replaced with alternatives.
The attributes on the <http>
element control some of the properties on the core filters.
AccessDecisionManager
implementation which should be used for authorizing HTTP requests. By default an AffirmativeBased
implementation is used for with a RoleVoter
and an AuthenticatedVoter
.
AuthenticationManager
used for the FilterChain
created by this http element.
create-session Controls the eagerness with which an HTTP session is created by Spring Security classes. Options include:
always
- Spring Security will proactively create a session if one does not exist.
ifRequired
- Spring Security will only create a session only if one is required (default value).
never
- Spring Security will never create a session, but will make use of one if the application does.
stateless
- Spring Security will not create a session and ignore the session for obtaining a Spring Authentication
.
true
. The default is true
.
AuthenticationEntryPoint
used will be set depending on which authentication mechanisms have been configured. This attribute allows this behaviour to be overridden by defining a customized AuthenticationEntryPoint
bean which will start the authentication process.
Subject
acquired from the JaasAuthenticationToken
which is implemented by adding a JaasApiIntegrationFilter
bean to the stack. Defaults to false
.
observeOncePerRequest
property of FilterSecurityInterceptor
. Defaults to true
.
realmName
property on BasicAuthenticationEntryPoint
.
RequestMatcher
strategy used in the FilterChainProxy
and the beans created by the intercept-url
to match incoming requests. Options are currently ant
, regex
and ciRegex
, for ant, regular-expression and case-insensitive regular-expression repsectively. A separate instance is created for eachintercept-url element using its pattern and method attributes. Ant paths are matched using an AntPathRequestMatcher
and regular expressions are matched using a RegexRequestMatcher
. See the Javadoc for these classes for more details on exactly how the matching is preformed. Ant paths are the default strategy.
RequestMatcher
that will determine if this FilterChain
should be used. This is a more powerful alternative to pattern.
none
. No security will be applied and none of Spring Security’s features will be available.
SecurityContextRepository
into the SecurityContextPersistenceFilter
.
HttpServletRequest
security methods such as isUserInRole()
and getPrincipal()
which are implemented by adding a SecurityContextHolderAwareRequestFilter
bean to the stack. Defaults to true
.
access
attribute, as described in the chapter on expression-based access-control. The default value is true.
This element allows you to set the errorPage
property for the default AccessDeniedHandler
used by the ExceptionTranslationFilter
, using the error-page attribute, or to supply your own implementation using theref attribute. This is discussed in more detail in the section on the ExceptionTranslationFilter.
This element allows for configuring additional (security) headers to be send with the response. It enables easy configuration for several headers and also allows for setting custom headers through the header element. Additional information, can be found in the Security Headers section of the reference.
Cache-Control
, Pragma
, and Expires
- Can be set using the cache-control element. This ensures that the browser does not cache your secured pages.
Strict-Transport-Security
- Can be set using the hsts element. This ensures that the browser automatically requests HTTPS for future requests.
X-Frame-Options
- Can be set using the frame-options element. The X-Frame-Options header can be used to prevent clickjacking attacks.
X-XSS-Protection
- Can be set using the xss-protection element. The X-XSS-Protection header can be used by browser to do basic control.
X-Content-Type-Options
- Can be set using the content-type-options element. The X-Content-Type-Options header prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions.
The attributes on the <headers>
element control the headers element.
Adds Cache-Control
, Pragma
, and Expires
headers to ensure that the browser does not cache your secured pages.
When enabled adds the Strict-Transport-Security header to the response for any secure request. This allows the server to instruct browsers to automatically use HTTPS for future requests.
When enabled adds the X-Frame-Options header to the response, this allows newer browsers to do some security checks and prevent clickjacking attacks.
policy
DENY
The page cannot be displayed in a frame, regardless of the site attempting to do so. This is the default when frame-options-policy is specified.
SAMEORIGIN
The page can only be displayed in a frame on the same origin as the page itself
ALLOW-FROM
origin The page can only be displayed in a frame on the specified origin.
In other words, if you specify DENY, not only will attempts to load the page in a frame fail when loaded from other sites, attempts to do so will fail when loaded from the same site. On the other hand, if you specify SAMEORIGIN, you can still use the page in a frame as long as the site including it in a frame it is the same as the one serving the page.
strategy
Select the AllowFromStrategy
to use when using the ALLOW-FROM policy.
static
Use a single static ALLOW-FROM value. The value can be set through the value attribute.
regexp
Use a regelur expression to validate incoming requests and if they are allowed. The regular expression can be set through the value attribute. The request parameter used to retrieve the value to validate can be specified using the from-parameter.
whitelist
A comma-seperated list containing the allowed domains. The comma-seperated list can be set through the value attribute. The request parameter used to retrieve the value to validate can be specified using the from-parameter.
AllowFromStrategy
. The reference to this bean can be specified through this ref attribute.
Adds the X-XSS-Protection header to the response to assist in protecting against reflected / Type-1 Cross-Site Scripting (XSS) attacks. This is in no-way a full protection to XSS attacks!
Add the X-Content-Type-Options header with the value of nosniff to the response. This disables MIME-sniffing for IE8+ and Chrome extensions.
Add additional headers to the response, both the name and value need to be specified.
Adds an AnonymousAuthenticationFilter
to the stack and an AnonymousAuthenticationProvider
. Required if you are using the IS_AUTHENTICATED_ANONYMOUSLY
attribute.
ROLE_ANONYMOUS
.
This element will add Cross Site Request Forger (CSRF) protection to the application. It also updates the default RequestCache to only replay "GET" requests upon successful authentication. Additional information can be found in the Cross Site Request Forgery (CSRF) section of the reference.
This element is used to add a filter to the filter chain. It doesn’t create any additional beans but is used to select a bean of type javax.servlet.Filter
which is already defined in the application context and add that at a particular position in the filter chain maintained by Spring Security. Full details can be found in the namespace chapter.
Defines the SecurityExpressionHandler
instance which will be used if expression-based access-control is enabled. A default implementation (with no ACL support) will be used if not supplied.
Used to add an UsernamePasswordAuthenticationFilter
to the filter stack and an LoginUrlAuthenticationEntryPoint
to the application context to provide authentication on demand. This will always take precedence over other namespace-created entry points. If no attributes are supplied, a login page will be generated automatically at the URL "/login" [23] The behaviour can be customized using the <form-login>
Attributes.
true
, the user will always start at the value given by default-target-url, regardless of how they arrived at the login page. Maps to the alwaysUseDefaultTargetUrl
property of UsernamePasswordAuthenticationFilter
. Default value is false
.
AuthenticationDetailsSource
which will be used by the authentication filter
AuthenticationFailureHandler
bean in the application context.
authenticationFailureUrl
property of UsernamePasswordAuthenticationFilter
. Defines the URL the browser will be redirected to on login failure. Defaults to /login?error
, which will be automatically handled by the automatic login page generator, re-rendering the login page with an error message.
AuthenticationSuccessHandler
bean in the application context. By default, an implementation of SavedRequestAwareAuthenticationSuccessHandler
is used and injected with the default-target-url.
defaultTargetUrl
property of UsernamePasswordAuthenticationFilter
. If not set, the default value is "/" (the application root). A user will be taken to this URL after logging in, provided they were not asked to login while attempting to access a secured resource, when they will be taken to the originally requested URL.
loginFormUrl
property of the LoginUrlAuthenticationEntryPoint
. Defaults to "/login".
filterProcessesUrl
property of UsernamePasswordAuthenticationFilter
. The default value is "/login".
Adds a BasicAuthenticationFilter
and BasicAuthenticationEntryPoint
to the configuration. The latter will only be used as the configuration entry point if form-based login is not enabled.
This is a top-level element which can be used to inject a custom implementation of HttpFirewall
into the FilterChainProxy
created by the namespace. The default implementation should be suitable for most applications.
This element is used to define the set of URL patterns that the application is interested in and to configure how they should be handled. It is used to construct the FilterInvocationSecurityMetadataSource
used by the FilterSecurityInterceptor
. It is also responsible for configuring a ChannelProcessingFilter
if particular URLs need to be accessed by HTTPS, for example. When matching the specified patterns against an incoming request, the matching is done in the order in which the elements are declared. So the most specific matches patterns should come first and the most general should come last.
FilterInvocationSecurityMetadataSource
for the defined URL pattern/method combination. This should be a comma-separated list of the security configuration attributes (such as role names).
<http>
configuration will have any effect on the request and there will be no security context available for its duration. Access to secured methods during the request will fail.
Note | |
---|---|
This property is invalid for filter-security-metadata-source |
request-matcher
attribute from the containing http element, so will default to ant path syntax.
<intercept-url>
element, then a ChannelProcessingFilter
will be added to the filter stack and its additional dependencies added to the application context.
If a <port-mappings>
configuration is added, this will be used to by the SecureChannelProcessor
and InsecureChannelProcessor
beans to determine the ports used for redirecting to HTTP/HTTPS.
Note | |
---|---|
This property is invalid for filter-security-metadata-source |
Adds a J2eePreAuthenticatedProcessingFilter to the filter chain to provide integration with container authentication.
Adds a LogoutFilter
to the filter stack. This is configured with a SecurityContextLogoutHandler
.
invalidateHttpSession
of the SecurityContextLogoutHandler
. Defaults to "true", so the session will be invalidated on logout.
logout-success-url The destination URL which the user will be taken to after logging out. Defaults to <form-login-login-page>/?logout (i.e. /login?logout)
Setting this attribute will inject the SessionManagementFilter
with a SimpleRedirectInvalidSessionStrategy
configured with the attribute value. When an invalid session ID is submitted, the strategy will be invoked, redirecting to the configured URL.
Similar to <form-login>
and has the same attributes. The default value for login-processing-url
is "/login/openid". An OpenIDAuthenticationFilter
and OpenIDAuthenticationProvider
will be registered. The latter requires a reference to a UserDetailsService
. Again, this can be specified by id
, using the user-service-ref
attribute, or will be located automatically in the application context.
The attribute-exchange
element defines the list of attributes which should be requested from the identity provider. An example can be found in the OpenID Support section of the namespace configuration chapter. More than one can be used, in which case each must have an identifier-match
attribute, containing a regular expression which is matched against the supplied OpenID identifier. This allows different attribute lists to be fetched from different providers (Google, Yahoo etc).
Attributes used when making an OpenID AX Fetch Request
By default, an instance of PortMapperImpl
will be added to the configuration for use in redirecting to secure and insecure URLs. This element can optionally be used to override the default mappings which that class defines. Each child <port-mapping>
element defines a pair of HTTP:HTTPS ports. The default mappings are 80:443 and 8080:8443. An example of overriding these can be found in the namespace introduction.
Provides a method to map http ports to https ports when forcing a redirect.
Adds the RememberMeAuthenticationFilter
to the stack. This in turn will be configured with either a TokenBasedRememberMeServices
, a PersistentTokenBasedRememberMeServices
or a user-specified bean implementing RememberMeServices
depending on the attribute settings.
authenticationSuccessHandler
property on the RememberMeAuthenticationFilter
if custom navigation is required. The value should be the name of a AuthenticationSuccessHandler
bean in the application context.
DataSource
bean. If this is set, PersistentTokenBasedRememberMeServices
will be used and configured with a JdbcTokenRepositoryImpl
instance.
AbstractRememberMeServices
.
AbstractRememberMeServices
.
AbstractRememberMeServices
. Should be set to a unique value to ensure that remember-me cookies are only valid within the one application [24]. If this is not set a secure random value will be generated. Since generating secure random values can take a while, setting this value explicitly can help improve startup times when using the remember me functionality.
RememberMeServices
as a bean alias, allowing it to be used by other beans in the application context.
RememberMeServices
implementation that will be used by the filter. The value should be the id
of a bean in the application context which implements this interface. Should also implement LogoutHandler
if a logout filter is in use.
PersistentTokenBasedRememberMeServices
but allows the use of a custom PersistentTokenRepository
bean.
tokenValiditySeconds
property of AbstractRememberMeServices
. Specifies the period in seconds for which the remember-me cookie should be valid. By default it will be valid for 14 days.
false
, secure cookies will not be used. Setting it to true
will always set the secure flag on the cookie. This attribute maps to the useSecureCookie
property of AbstractRememberMeServices
.
UserDetailsService
, so there has to be one defined in the application context. If there is only one, it will be selected and used automatically by the namespace configuration. If there are multiple instances, you can specify a bean id
explicitly using this attribute.
Sets the RequestCache
instance which will be used by the ExceptionTranslationFilter
to store request information before invoking an AuthenticationEntryPoint
.
Session-management related functionality is implemented by the addition of a SessionManagementFilter
to the filter stack.
SessionManagementFilter
with a SimpleRedirectInvalidSessionStrategy
configured with the attribute value. When an invalid session ID is submitted, the strategy will be invoked, redirecting to the configured URL.
session-fixation-protection Indicates how session fixation protection will be applied when a user authenticates. If set to "none", no protection will be applied. "newSession" will create a new empty session, with only Spring Security-related attributes migrated. "migrateSession" will create a new session and copy all session attributes to the new session. In Servlet 3.1 (Java EE 7) and newer containers, specifying "changeSessionId" will keep the existing session and use the container-supplied session fixation protection (HttpServletRequest#changeSessionId()). Defaults to "changeSessionId" in Servlet 3.1 and newer containers, "migrateSession" in older containers. Throws an exception if "changeSessionId" is used in older containers.
If session fixation protection is enabled, the SessionManagementFilter
is injected with an appropriately configured DefaultSessionAuthenticationStrategy
. See the Javadoc for this class for more details.
Adds support for concurrent session control, allowing limits to be placed on the number of active sessions a user can have. A ConcurrentSessionFilter
will be created, and a ConcurrentSessionControlAuthenticationStrategy
will be used with the SessionManagementFilter
. If a form-login
element has been declared, the strategy object will also be injected into the created authentication filter. An instance of SessionRegistry
(a SessionRegistryImpl
instance unless the user wishes to use a custom bean) will be created for use by the strategy.
SessionAuthenticationException
will be raised when a user attempts to exceed the maximum allowed number of sessions. The default behaviour is to expire the original session.
exception-if-maximum-exceeded
is set. If no value is supplied, an expiry message will just be written directly back to the response.
maximumSessions
property of ConcurrentSessionControlAuthenticationStrategy
.
Adds support for X.509 authentication. An X509AuthenticationFilter
will be added to the stack and an Http403ForbiddenEntryPoint
bean will be created. The latter will only be used if no other authentication mechanisms are in use (its only functionality is to return an HTTP 403 error code). A PreAuthenticatedAuthenticationProvider
will also be created which delegates the loading of user authorities to a UserDetailsService
.
Used to explicitly configure a FilterChainProxy instance with a FilterChainMap
Used within to define a specific URL pattern and the list of filters which apply to the URLs matching that pattern. When multiple filter-chain elements are assembled in a list in order to configure a FilterChainProxy, the most specific patterns must be placed at the top of the list, with most general ones at the bottom.
Filter
. The value "none" means that no Filter’s should be used for this `FilterChain
.
Used to explicitly configure a FilterSecurityMetadataSource bean for use with a FilterSecurityInterceptor. Usually only needed if you are configuring a FilterChainProxy explicitly, rather than using the<http> element. The intercept-url elements used should only contain pattern, method and access attributes. Any others will result in a configuration error.
Spring Security 4.0+ provides support for authorizing messages. One concrete example of where this is useful is to provide authorization in WebSocket based applications.
The websocket-message-broker element has two different modes. If the websocket-message-broker@id is not specified, then it will do the following things:
@AuthenticationPrincipal
to resolve the principal of the current Authentication
If additional control is necessary, the id can be specified and a ChannelSecurityInterceptor will be assigned to the specified id. All the wiring with Spring’s messaging infrastructure can then be done manually. This is more cumbersome, but provides greater control over the configuration.
Defines an authorization rule for a message.
Before Spring Security 3.0, an AuthenticationManager
was automatically registered internally. Now you must register one explicitly using the <authentication-manager>
element. This creates an instance of Spring Security’s ProviderManager
class, which needs to be configured with a list of one or more AuthenticationProvider
instances. These can either be created using syntax elements provided by the namespace, or they can be standard bean definitions, marked for addition to the list using the authentication-provider
element.
Every Spring Security application which uses the namespace must have include this element somewhere. It is responsible for registering the AuthenticationManager
which provides authentication services to the application. All elements which create AuthenticationProvider
instances should be children of this element.
eraseCredentialsAfterAuthentication
property of the ProviderManager
. This is discussed in the Core Services chapter.
Unless used with a ref
attribute, this element is shorthand for configuring a DaoAuthenticationProvider. DaoAuthenticationProvider
loads user information from a UserDetailsService
and compares the username/password combination with the values supplied at login. The UserDetailsService
instance can be defined either by using an available namespace element ( jdbc-user-service
or by using the user-service-ref
attribute to point to a bean defined elsewhere in the application context). You can find examples of these variations in the namespace introduction.
If you have written your own AuthenticationProvider
implementation (or want to configure one of Spring Security’s own implementations as a traditional bean for some reason, then you can use the following syntax to add it to the internal `ProviderManager’s list:
<security:authentication-manager> <security:authentication-provider ref="myAuthenticationProvider" /> </security:authentication-manager> <bean id="myAuthenticationProvider" class="com.something.MyAuthenticationProvider"/>
Causes creation of a JDBC-based UserDetailsService.
The default is
select username, authority from authorities where username = ?
group-authorities-by-username-query An SQL statement to query user’s group authorities given a username. The default is
select g.id, g.group_name, ga.authority from groups g, group_members gm, group_authorities ga where gm.username = ? and g.id = ga.group_id and g.id = gm.group_id
Authentication providers can optionally be configured to use a password encoder as described in the namespace introduction. This will result in the bean being injected with the appropriate PasswordEncoder
instance, potentially with an accompanying SaltSource
bean to provide salt values for hashing.
Password salting strategy. A system-wide constant or a property from the UserDetails object can be used.
Creates an in-memory UserDetailsService from a properties file or a list of "user" child elements. Usernames are converted to lower-case internally to allow for case-insensitive lookups, so this should not be used if case-sensitivity is required.
Represents a user in the application.
This element is the primary means of adding support for securing methods on Spring Security beans. Methods can be secured by the use of annotations (defined at the interface or class level) or by defining a set of pointcuts as child elements, using AspectJ syntax.
AccessDecisionManager
configuration as web security, but this can be overridden using this attribute. By default an AffirmativeBased implementation is used for with a RoleVoter and an AuthenticatedVoter.
AuthenticationManager
that should be used for method security.
Jsr250Voter
to the AccessDecisionManager
, so you need to make sure you do this if you are using a custom implementation and want to use these annotations.
MethodSecurityMetadataSource
instance can be supplied which will take priority over other sources (such as the default annotations).
AnnotationSecurityAspect
from the spring-security-aspects
module.
It is important to note that AspectJ follows Java’s rule that annotations on interfaces are not inherited. This means that methods that define the Security annotaitons on the interface will not be secured. Instead, you must place the Security annotation on the class when using AspectJ.
This element can be used to decorate an AfterInvocationProvider
for use by the security interceptor maintained by the <global-method-security>
namespace. You can define zero or more of these within the global-method-security
element, each with a ref
attribute pointing to an AfterInvocationProvider
bean instance within your application context.
Allows the default expression-based mechanism for handling Spring Security’s pre and post invocation annotations (@PreFilter, @PreAuthorize, @PostFilter, @PostAuthorize) to be replace entirely. Only applies if these annotations are enabled.
Defines the PrePostInvocationAttributeFactory instance which is used to generate pre and post invocation metadata from the annotated methods.
Customizes the PostInvocationAdviceProvider
with the ref as the PostInvocationAuthorizationAdvice
for the <pre-post-annotation-handling> element.
Customizes the PreInvocationAuthorizationAdviceVoter
with the ref as the PreInvocationAuthorizationAdviceVoter
for the <pre-post-annotation-handling> element.
<protect-pointcut>
Rather than defining security attributes on an individual method or class basis using the @Secured
annotation, you can define cross-cutting security constraints across whole sets of methods and interfaces in your service layer using the <protect-pointcut>
element. You can find an example in the namespace introduction.
Can be used inside a bean definition to add a security interceptor to the bean and set up access configuration attributes for the bean’s methods
Creates a MethodSecurityMetadataSource instance
Defines a protected method and the access control configuration attributes that apply to it. We strongly advise you NOT to mix "protect" declarations with any services provided "global-method-security".
LDAP is covered in some details in its own chapter. We will expand on that here with some explanation of how the namespace options map to Spring beans. The LDAP implementation uses Spring LDAP extensively, so some familiarity with that project’s API may be useful.
<ldap-server>
Element
This element sets up a Spring LDAP ContextSource
for use by the other LDAP beans, defining the location of the LDAP server and other information (such as a username and password, if it doesn’t allow anonymous access) for connecting to it. It can also be used to create an embedded server for testing. Details of the syntax for both options are covered in the LDAP chapter. The actual ContextSource
implementation is DefaultSpringSecurityContextSource
which extends Spring LDAP’s LdapContextSource
class. The manager-dn
and manager-password
attributes map to the latter’s userDn
and password
properties respectively.
If you only have one server defined in your application context, the other LDAP namespace-defined beans will use it automatically. Otherwise, you can give the element an "id" attribute and refer to it from other namespace beans using the server-ref
attribute. This is actually the bean id
of the ContextSource
instance, if you want to use it in other traditional Spring beans.
This element is shorthand for the creation of an LdapAuthenticationProvider
instance. By default this will be configured with a BindAuthenticator
instance and a DefaultAuthoritiesPopulator
. As with all namespace authentication providers, it must be included as a child of the authentication-provider
element.
DefaultLdapAuthoritiesPopulator’s `groupRoleAttribute
property. Defaults to "cn".
DefaultLdapAuthoritiesPopulator’s `groupSearchBase
constructor argument. Defaults to "" (searching from the root).
DefaultLdapAuthoritiesPopulator’s `groupSearchFilter
property. Defaults to (uniqueMember={0}). The substituted parameter is the DN of the user.
DefaultLdapAuthoritiesPopulator’s `rolePrefix
property. Defaults to "ROLE_". Use the value "none" for no prefix in cases where the default is non-empty.
userDnPatterns
property of AbstractLdapAuthenticator
. The value is a specific pattern used to build the user’s DN, for example "uid={0},ou=people". The key "{0}" must be present and will be substituted with the username.
user-search-base Search base for user searches. Defaults to "". Only used with a 'user-search-filter'.
If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search. The BindAuthenticator
will be configured with a FilterBasedLdapUserSearch
and the attribute values map directly to the first two arguments of that bean’s constructor. If these attributes aren’t set and no user-dn-pattern
has been supplied as an alternative, then the default search values of user-search-filter="(uid={0})"
and user-search-base=""
will be used.
user-search-filter The LDAP filter used to search for users (optional). For example "(uid={0})". The substituted parameter is the user’s login name.
If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search. The BindAuthenticator
will be configured with a FilterBasedLdapUserSearch
and the attribute values map directly to the first two arguments of that bean’s constructor. If these attributes aren’t set and no user-dn-pattern
has been supplied as an alternative, then the default search values of user-search-filter="(uid={0})"
and user-search-base=""
will be used.
This is used as child element to <ldap-provider>
and switches the authentication strategy from BindAuthenticator
to PasswordComparisonAuthenticator
.
This element configures an LDAP UserDetailsService
. The class used is LdapUserDetailsService
which is a combination of a FilterBasedLdapUserSearch
and a DefaultLdapAuthoritiesPopulator
. The attributes it supports have the same usage as in <ldap-provider>
.
[22] See the introductory chapter for how to set up the mapping from your web.xml
[23] This feature is really just provided for convenience and is not intended for production (where a view technology will have been chosen and can be used to render a customized login page). The class DefaultLoginPageGeneratingFilter
is responsible for rendering the login page and will provide login forms for both normal form login and/or OpenID if required.
[24] This doesn’t affect the use of PersistentTokenBasedRememberMeServices
, where the tokens are stored on the server side.