Spring Security has its own taglib which provides basic support for accessing security information and applying security constraints in JSPs.
To use any of the tags, you must have the security taglib declared in your JSP:
<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
This tag is used to determine whether its contents should be evaluated or not. In
Spring Security 3.0, it can be used in two ways [25]. The first approach uses a web-security
expression, specified in the access attribute of the tag. The
expression evaluation will be delegated to the
SecurityExpressionHandler<FilterInvocation> defined in the application
context (you should have web expressions enabled in your <http>
namespace configuration to make sure this service is available). So, for example, you
might
have
<sec:authorize access="hasRole('supervisor')"> This content will only be visible to users who have the "supervisor" authority in their list of <tt>GrantedAuthority</tt>s. </sec:authorize>
A common requirement is to only show a particular link, if the user is actually allowed to click it. How can we determine in advance whether something will be allowed? This tag can also operate in an alternative mode which allows you to define a particular URL as an attribute. If the user is allowed to invoke that URL, then the tag body will be evaluated, otherwise it will be skipped. So you might have something like
<sec:authorize url="/admin"> This content will only be visible to users who are authorized to send requests to the "/admin" URL. </sec:authorize>
To
use this tag there must also be an instance of
WebInvocationPrivilegeEvaluator in your application
context. If you are using the namespace, one will automatically be registered. This is
an instance of DefaultWebInvocationPrivilegeEvaluator, which
creates a dummy web request for the supplied URL and invokes the security interceptor to
see whether the request would succeed or fail. This allows you to delegate to the
access-control setup you defined using intercept-url declarations
within the <http> namespace configuration and saves having to
duplicate the information (such as the required roles) within your JSPs. This approach
can also be combined with a method attribute, supplying the HTTP
method, for a more specific match.
The boolean result of evaluating the tag (whether it grants or denies access) can be
stored in a page context scope variable by setting the var attribute
to the variable name, avoiding the need for duplicating and re-evaluating the condition
at other points in the page.
Hiding a link in a page for unauthorized users doesn't prevent them from accessing
the URL. They could just type it into their browser directly, for example. As part
of your testing process, you may want to reveal the hidden areas in order to check
that links really are secured at the back end. If you set the system property
spring.security.disableUISecurity to true,
the authorize tag will still run but will not hide its contents.
By default it will also surround the content with <span
class="securityHiddenUI">...</span> tags. This allows you to
display “hidden” content with a particular CSS style such as a
different background colour. Try running the “tutorial” sample
application with this property enabled, for example.
You can also set the properties spring.security.securedUIPrefix
and spring.security.securedUISuffix if you want to change
surrounding text from the default span tags (or use empty strings
to remove it completely).
This tag allows access to the current Authentication
object stored in the security context. It renders a property of the object directly in
the JSP. So, for example, if the principal property of the
Authentication is an instance of Spring Security's
UserDetails object, then using
<sec:authentication property="principal.username" /> will render
the name of the current user.
Of course, it isn't necessary to use JSP tags for this kind of thing and some people
prefer to keep as little logic as possible in the view. You can access the
Authentication object in your MVC controller (by calling
SecurityContextHolder.getContext().getAuthentication()) and add the data
directly to your model for rendering by the view.
This tag is only valid when used with Spring Security's ACL module. It checks a comma-separated list of required permissions for a specified domain object. If the current user has any of those permissions, then the tag body will be evaluated. If they don't, it will be skipped. An example might be
<sec:accesscontrollist hasPermission="1,2" domainObject="${someObject}"> This will be shown if the user has either of the permissions represented by the values "1" or "2" on the given object. </sec:accesscontrollist>
The permissions are passed to the PermissionFactory
defined in the application context, converting them to ACL
Permission instances, so they may be any format which is
supported by the factory - they don't have to be integers, they could be strings like
READ or WRITE. If no
PermissionFactory is found, an instance of
DefaultPermissionFactory will be used. The
AclServicefrom the application context will be used to
load the Acl instance for the supplied object. The
Acl will be invoked with the required permissions to
check if any of them are granted.
This tag also supports the var attribute, in the same way as the
authorize tag.