Add missing language attributes to programlisting tags for highlighting.
This commit is contained in:
parent
5caa41753a
commit
4e349904e5
|
@ -1,4 +1,4 @@
|
|||
// Docbook and Javadoc building and uploading tasks
|
||||
// Docbook and Javadoc building and uploading tasks
|
||||
apply plugin: 'base'
|
||||
|
||||
task docs {
|
||||
|
@ -47,6 +47,12 @@ project('manual') {
|
|||
}
|
||||
}
|
||||
|
||||
task reference (type: Copy) {
|
||||
dependsOn 'manual:docbook'
|
||||
destinationDir = buildDir
|
||||
with(project('manual').spec)
|
||||
}
|
||||
|
||||
task apidocs(type: Javadoc) {
|
||||
destinationDir = new File(buildDir, 'apidocs')
|
||||
title = "Spring Security $version API"
|
||||
|
|
|
@ -282,7 +282,7 @@
|
|||
<answer><para>Make sure you have added the listener to your web.xml file. It is
|
||||
essential to make sure that the Spring Security session registry is notified
|
||||
when a session is destroyed. Without it, the session information will not be
|
||||
removed from the registry.</para><programlisting><![CDATA[
|
||||
removed from the registry.</para><programlisting language="xml"><![CDATA[
|
||||
<listener>
|
||||
<listener-class>org.springframework.security.ui.session.HttpSessionEventPublisher</listener-class>
|
||||
</listener> ]]>
|
||||
|
|
|
@ -54,7 +54,7 @@
|
|||
<classname>SecurityContextHolder</classname> if there is no existing
|
||||
<interfacename>Authentication</interfacename> held there. The definition of the filter
|
||||
and authentication provider appears as follows:</para>
|
||||
<para> <programlisting>
|
||||
<para> <programlisting language="xml">
|
||||
<![CDATA[
|
||||
<bean id="anonymousAuthFilter"
|
||||
class="org.springframework.security.web.authentication.AnonymousAuthenticationFilter">
|
||||
|
@ -89,7 +89,7 @@
|
|||
<literal>InMemoryDaoImpl</literal>'s <literal>userMap</literal> property.</para>
|
||||
<para>As explained earlier, the benefit of anonymous authentication is that all URI patterns
|
||||
can have security applied to them. For example:</para>
|
||||
<para> <programlisting>
|
||||
<para> <programlisting language="xml">
|
||||
<![CDATA[
|
||||
<bean id="filterSecurityInterceptor"
|
||||
class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
|
||||
|
|
|
@ -136,7 +136,7 @@ create table acl_entry (
|
|||
<section>
|
||||
<title>PostgreSQL</title>
|
||||
<para>
|
||||
<programlisting>create table acl_sid(
|
||||
<programlisting language="ddl">create table acl_sid(
|
||||
id bigserial not null primary key,
|
||||
principal boolean not null,
|
||||
sid varchar(100) not null,
|
||||
|
|
|
@ -602,7 +602,7 @@
|
|||
<interfacename>AuthenticationProvider</interfacename> 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
|
||||
<classname>ProviderManager</classname>'s list: <programlisting><![CDATA[
|
||||
<classname>ProviderManager</classname>'s list: <programlisting language="xml"><![CDATA[
|
||||
<security:authentication-manager>
|
||||
<security:authentication-provider ref="myAuthenticationProvider" />
|
||||
</security:authentication-manager>
|
||||
|
|
|
@ -17,7 +17,7 @@
|
|||
<interfacename>AccessDecisionManager</interfacename>s when making authorization
|
||||
decisions.</para>
|
||||
<para><interfacename>GrantedAuthority</interfacename> is an interface with only one method:
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
String getAuthority();
|
||||
</programlisting> This method allows
|
||||
<interfacename>AccessDecisionManager</interfacename>s to obtain a precise
|
||||
|
@ -63,7 +63,7 @@
|
|||
final access control decisions. The
|
||||
<interfacename>AccessDecisionManager</interfacename> interface contains three
|
||||
methods:
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
void decide(Authentication authentication, Object secureObject,
|
||||
Collection<ConfigAttribute> attrs) throws AccessDeniedException;
|
||||
boolean supports(ConfigAttribute attribute);
|
||||
|
@ -112,7 +112,7 @@
|
|||
based on its assessment of the votes.</para>
|
||||
<para>The <interfacename>AccessDecisionVoter</interfacename> interface has three
|
||||
methods:
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attrs);
|
||||
boolean supports(ConfigAttribute attribute);
|
||||
boolean supports(Class clazz);
|
||||
|
@ -243,7 +243,7 @@ boolean supports(Class clazz);
|
|||
<para>A common services layer method we've all written at one stage or another looks like
|
||||
this:</para>
|
||||
<para>
|
||||
<programlisting>public Contact getById(Integer id);</programlisting>
|
||||
<programlisting language="java">public Contact getById(Integer id);</programlisting>
|
||||
</para>
|
||||
<para>Quite often, only principals with permission to read the <literal>Contact</literal>
|
||||
should be allowed to obtain it. In this situation the
|
||||
|
@ -251,7 +251,7 @@ boolean supports(Class clazz);
|
|||
<classname>AbstractSecurityInterceptor</classname> will not suffice. This is because the
|
||||
identity of the <literal>Contact</literal> is all that is available before the secure object
|
||||
is invoked. The <classname>AclEntryAfterInvocationProvider</classname> delivers a solution,
|
||||
and is configured as follows: <programlisting><![CDATA[
|
||||
and is configured as follows: <programlisting language="xml"><![CDATA[
|
||||
<bean id="afterAclRead"
|
||||
class="org.springframework.security.acls.afterinvocation.AclEntryAfterInvocationProvider">
|
||||
<constructor-arg ref="aclService"/>
|
||||
|
@ -274,7 +274,7 @@ boolean supports(Class clazz);
|
|||
<classname>AclEntryAfterInvocationCollectionFilteringProvider</classname>. It is designed
|
||||
to remove <literal>Collection</literal> or array elements for which a principal does not
|
||||
have access. It never thrown an <classname>AccessDeniedException</classname> - simply
|
||||
silently removes the offending elements. The provider is configured as follows: <programlisting><![CDATA[
|
||||
silently removes the offending elements. The provider is configured as follows: <programlisting language="xml"><![CDATA[
|
||||
<bean id="afterAclCollectionRead"
|
||||
class="org.springframework.security.acls.afterinvocation.AclEntryAfterInvocationCollectionFilteringProvider">
|
||||
<constructor-arg ref="aclService"/>
|
||||
|
@ -311,7 +311,7 @@ boolean supports(Class clazz);
|
|||
<classname>RoleHierarchyVoter</classname>, is configured with a <interfacename>RoleHierarchy</interfacename>,
|
||||
from which it obtains all the <quote>reachable authorities</quote> which the user is assigned.
|
||||
A typical configuration might look like this:
|
||||
<programlisting><![CDATA[
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean id="roleVoter" class="org.springframework.security.access.vote.RoleHierarchyVoter">
|
||||
<constructor-arg ref="roleHierarchy" />
|
||||
</class>
|
||||
|
|
|
@ -79,7 +79,7 @@
|
|||
a "nonce". This is a value the server generates. Spring Security's nonce adopts the
|
||||
following format:</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))
|
||||
|
||||
expirationTime: The date and time when the nonce expires, expressed in milliseconds
|
||||
|
@ -120,7 +120,7 @@
|
|||
<literal>DigestAuthenticationFilter</literal> in the filter chain. The application
|
||||
context will need to define the <literal>DigestAuthenticationFilter</literal> and
|
||||
its required collaborators:</para>
|
||||
<para> <programlisting><![CDATA[
|
||||
<para> <programlisting language="xml"><![CDATA[
|
||||
<bean id="digestFilter" class=
|
||||
"org.springframework.security.web.authentication.www.DigestAuthenticationFilter">
|
||||
<property name="userDetailsService" ref="jdbcDaoImpl"/>
|
||||
|
|
|
@ -214,7 +214,7 @@
|
|||
required. </para>
|
||||
<para>You will need to add a <classname>ServiceProperties</classname> bean to your
|
||||
application context. This represents your CAS service:</para>
|
||||
<para> <programlisting><![CDATA[
|
||||
<para> <programlisting language="xml"><![CDATA[
|
||||
<bean id="serviceProperties"
|
||||
class="org.springframework.security.cas.ServiceProperties">
|
||||
<property name="service"
|
||||
|
@ -230,7 +230,7 @@
|
|||
order to gain access to the service.</para>
|
||||
<para>The following beans should be configured to commence the CAS authentication process
|
||||
(assuming you're using a namespace configuration):</para>
|
||||
<para> <programlisting><![CDATA[
|
||||
<para> <programlisting language="xml"><![CDATA[
|
||||
<security:http entry-point-ref="casEntryPoint">
|
||||
...
|
||||
<custom-filter position="FORM_LOGIN_FILTER" ref="myFilter" />
|
||||
|
@ -262,7 +262,7 @@
|
|||
to the enterprise's CAS login server. This is where the user's browser will be
|
||||
redirected.</para>
|
||||
<para>Next you need to add a <literal>CasAuthenticationProvider</literal> and its
|
||||
collaborators: <programlisting><![CDATA[
|
||||
collaborators: <programlisting language="xml"><![CDATA[
|
||||
<security:authentication-manager alias="authenticationManager">
|
||||
<security:authentication-provider ref="casAuthenticationProvider" />
|
||||
</security:authentication-manager>
|
||||
|
@ -306,7 +306,7 @@
|
|||
<literal>ProxyTicketReceptor</literal> by adding the following to your
|
||||
web application's <literal>web.xml</literal>:</para>
|
||||
|
||||
<para><programlisting>
|
||||
<para><programlisting language="xml">
|
||||
<servlet>
|
||||
<servlet-name>casproxy</servlet-name>
|
||||
<servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class>
|
||||
|
|
|
@ -37,7 +37,7 @@
|
|||
<literal><intercept-url></literal> element and this is the simplest (and
|
||||
recommended approach).</para>
|
||||
<para>To configure channel security explicitly, you would define the following the filter in
|
||||
your application context: <programlisting><![CDATA[
|
||||
your application context: <programlisting language="xml"><![CDATA[
|
||||
<bean id="channelProcessingFilter"
|
||||
class="org.springframework.security.web.access.channel.ChannelProcessingFilter">
|
||||
<property name="channelDecisionManager" ref="channelDecisionManager"/>
|
||||
|
|
|
@ -199,7 +199,7 @@
|
|||
xlink:href="#tech-intro-sec-context-persistence">Technical Overview</link> chapter so
|
||||
you might want to re-read that section at this point. Let's first take a look at how you
|
||||
would configure it for use with a <classname>FilterChainProxy</classname>. A basic
|
||||
configuration only requires the bean itself <programlisting><![CDATA[
|
||||
configuration only requires the bean itself <programlisting language="xml"><![CDATA[
|
||||
<bean id="securityContextPersistenceFilter"
|
||||
class="org.springframework.security.web.context.SecurityContextPersistenceFilter"/>
|
||||
]]></programlisting> As we saw previously, this filter has two main tasks. It is responsible for
|
||||
|
@ -291,7 +291,7 @@ public interface SecurityContextRepository {
|
|||
</orderedlist> The login form simply contains <literal>j_username</literal> and
|
||||
<literal>j_password</literal> input fields, and posts to the URL that is monitored by
|
||||
the filter (by default this is <literal>/j_spring_security_check</literal>). The basic
|
||||
filter configuration looks something like this: <programlisting><![CDATA[
|
||||
filter configuration looks something like this: <programlisting language="xml"><![CDATA[
|
||||
<bean id="authenticationFilter" class=
|
||||
"org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
|
||||
<property name="authenticationManager" ref="authenticationManager"/>
|
||||
|
|
|
@ -127,7 +127,7 @@
|
|||
<interfacename>UserDetailsService</interfacename> interfaces. Recall that the contract
|
||||
for <interfacename>UserDetailsService</interfacename> is a single method:</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
|
||||
</programlisting> </para>
|
||||
<para>The returned <interfacename>UserDetails</interfacename> is an interface that provides
|
||||
|
@ -153,19 +153,19 @@
|
|||
Security, when you don't really want to spend time configuring databases or writing
|
||||
<interfacename>UserDetailsService</interfacename> implementations. For this sort of
|
||||
situation, a simple option is to use the <literal>user-service</literal> element
|
||||
from the security <link xlink:href="#ns-minimal">namespace</link>: <programlisting><![CDATA[
|
||||
from the security <link xlink:href="#ns-minimal">namespace</link>: <programlisting language="xml"><![CDATA[
|
||||
<user-service id="userDetailsService">
|
||||
<user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
|
||||
<user name="bob" password="bobspassword" authorities="ROLE_USER" />
|
||||
</user-service>
|
||||
]]>
|
||||
</programlisting> This also supports the use of an external properties
|
||||
file: <programlisting><![CDATA[
|
||||
file: <programlisting language="xml"><![CDATA[
|
||||
<user-service id="userDetailsService" properties="users.properties"/>
|
||||
]]></programlisting> The properties file should contain entries in the form
|
||||
<programlisting>username=password,grantedAuthority[,grantedAuthority][,enabled|disabled]</programlisting>
|
||||
<programlisting language="txt">username=password,grantedAuthority[,grantedAuthority][,enabled|disabled]</programlisting>
|
||||
For example
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled
|
||||
bob=bobspassword,ROLE_USER,enabled</programlisting></para>
|
||||
</section>
|
||||
|
@ -230,7 +230,7 @@
|
|||
algorithm is a one-way function which produces a piece of fixed-length output data
|
||||
(the hash) from some input data, such as a password. As an example, the MD5 hash of
|
||||
the string <quote>password</quote> (in hexadecimal) is
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
5f4dcc3b5aa765d61d8327deb882cf99
|
||||
</programlisting> A hash is
|
||||
<quote>one-way</quote> in the sense that it is very difficult (effectively
|
||||
|
|
|
@ -244,7 +244,7 @@
|
|||
sufficient length to accommodate all common usage scenarios.</para>
|
||||
<para>The following fragment of code shows how to create an <literal>Acl</literal>, or
|
||||
modify an existing
|
||||
<literal>Acl</literal>:<programlisting>// Prepare the information we'd like in our access control entry (ACE)
|
||||
<literal>Acl</literal>:<programlisting language="java">// Prepare the information we'd like in our access control entry (ACE)
|
||||
ObjectIdentity oi = new ObjectIdentityImpl(Foo.class, new Long(44));
|
||||
Sid sid = new PrincipalSid("Samantha");
|
||||
Permission p = BasePermission.ADMINISTRATION;
|
||||
|
|
|
@ -94,7 +94,7 @@
|
|||
to <literal>true</literal>. Spring Security will then expect the
|
||||
<literal>access</literal> attributes of the <literal><intercept-url></literal>
|
||||
elements to contain Spring EL expressions. The expressions should evaluate to a boolean,
|
||||
defining whether access should be allowed or not. For example:<programlisting><![CDATA[
|
||||
defining whether access should be allowed or not. For example:<programlisting language="xml"><![CDATA[
|
||||
<http use-expressions="true">
|
||||
<intercept-url pattern="/admin*"
|
||||
access="hasRole('admin') and hasIpAddress('192.168.1.0/24')"/>
|
||||
|
@ -129,21 +129,21 @@
|
|||
<literal>@PreFilter</literal>, <literal>@PostAuthorize</literal> and
|
||||
<literal>@PostFilter</literal>. Their use is enabled through the
|
||||
<literal>global-method-security</literal> namespace
|
||||
element:<programlisting><![CDATA[<global-method-security pre-post-annotations="enabled"/>]]></programlisting></para>
|
||||
element:<programlisting language="xml"><![CDATA[<global-method-security pre-post-annotations="enabled"/>]]></programlisting></para>
|
||||
<section>
|
||||
<title>Access Control using <literal>@PreAuthorize</literal> and
|
||||
<literal>@PostAuthorize</literal></title>
|
||||
<para>The most obviously useful annotation is <literal>@PreAuthorize</literal> which
|
||||
decides whether a method can actually be invoked or not. For example (from the
|
||||
<quote>Contacts</quote> sample
|
||||
application)<programlisting>
|
||||
application)<programlisting language="java">
|
||||
@PreAuthorize("hasRole('ROLE_USER')")
|
||||
public void create(Contact contact);</programlisting>which
|
||||
means that access will only be allowed for users with the role "ROLE_USER".
|
||||
Obviously the same thing could easily be achieved using a traditional
|
||||
configuration and a simple configuration attribute for the required role. But
|
||||
what
|
||||
about:<programlisting>
|
||||
about:<programlisting language="java">
|
||||
@PreAuthorize("hasPermission(#contact, 'admin')")
|
||||
public void deletePermission(Contact contact, Sid recipient, Permission permission);</programlisting>Here
|
||||
we're actually using a method argument as part of the expression to decide
|
||||
|
@ -156,7 +156,7 @@
|
|||
the expression, so you can also access properties on the arguments. For example,
|
||||
if you wanted a particular method to only allow access to a user whose username
|
||||
matched that of the contact, you could write</para>
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
@PreAuthorize("#contact.name == authentication.name")
|
||||
public void doSomething(Contact contact);</programlisting>
|
||||
<para>Here we are accessing another built–in expression, <literal>authentication</literal>,
|
||||
|
@ -178,7 +178,7 @@
|
|||
<para>As you may already be aware, Spring Security supports filtering of collections
|
||||
and arrays and this can now be achieved using expressions. This is most commonly
|
||||
performed on the return value of a method. For
|
||||
example:<programlisting> @PreAuthorize("hasRole('ROLE_USER')")
|
||||
example:<programlisting language="java"> @PreAuthorize("hasRole('ROLE_USER')")
|
||||
@PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')")
|
||||
public List<Contact> getAll();</programlisting>When
|
||||
using the <literal>@PostFilter</literal> annotation, Spring Security iterates
|
||||
|
|
|
@ -26,7 +26,7 @@
|
|||
<para>The login form simply contains <literal>j_username</literal> and
|
||||
<literal>j_password</literal> input fields, and posts to a URL that is monitored by the
|
||||
filter (by default <literal>/j_spring_security_check</literal>). You should add an
|
||||
<literal>UsernamePasswordAuthenticationFilter</literal> to your application context: <programlisting><![CDATA[
|
||||
<literal>UsernamePasswordAuthenticationFilter</literal> to your application context: <programlisting language="xml"><![CDATA[
|
||||
<bean id="authenticationProcessingFilter" class=
|
||||
"org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
|
||||
<property name="authenticationManager" ref="authenticationManager"/>
|
||||
|
|
|
@ -300,7 +300,7 @@
|
|||
ultimate documentation for a project and often the simplest place to find out how
|
||||
something actually works. </para>
|
||||
<para>To obtain the source for the project, use the following git command:
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
git clone git://git.springsource.org/spring-security/spring-security.git
|
||||
</programlisting>
|
||||
</para>
|
||||
|
|
|
@ -11,15 +11,15 @@
|
|||
Java Authentication and Authorization Service (JAAS). This package is discussed in
|
||||
detail below.</para>
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="jaas-abstractjaasauthenticationprovider">
|
||||
<info>
|
||||
<title>AbstractJaasAuthenticationProvider</title>
|
||||
</info>
|
||||
<para>The <classname>AbstractJaasAuthenticationProvider</classname> is the basis for the
|
||||
provided JAAS <interfacename>AuthenticationProvider</interfacename> implementations. Subclasses
|
||||
must implement a method that creates the <classname>LoginContext</classname>. The
|
||||
<classname>AbstractJaasAuthenticationProvider</classname> has a number of dependencies that can
|
||||
<info>
|
||||
<title>AbstractJaasAuthenticationProvider</title>
|
||||
</info>
|
||||
<para>The <classname>AbstractJaasAuthenticationProvider</classname> is the basis for the
|
||||
provided JAAS <interfacename>AuthenticationProvider</interfacename> implementations. Subclasses
|
||||
must implement a method that creates the <classname>LoginContext</classname>. The
|
||||
<classname>AbstractJaasAuthenticationProvider</classname> has a number of dependencies that can
|
||||
be injected into it that are discussed below.</para>
|
||||
|
||||
<section xml:id="jaas-callbackhandler">
|
||||
|
@ -93,55 +93,55 @@
|
|||
an implementation-specific meaning. However, there is a
|
||||
<literal>TestAuthorityGranter</literal> in the unit tests that demonstrates a simple
|
||||
<literal>AuthorityGranter</literal> implementation.</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="jaas-defaultjaasauthenticationprovider">
|
||||
<info>
|
||||
<title>DefaultJaasAuthenticationProvider</title>
|
||||
</info>
|
||||
<para>The <classname>DefaultJaasAuthenticationProvider</classname> allows a JAAS
|
||||
<classname>Configuration</classname> object to be injected into it as a dependency. It then
|
||||
creates a <classname>LoginContext</classname> using the injected JAAS <classname>Configuration</classname>.
|
||||
<info>
|
||||
<title>DefaultJaasAuthenticationProvider</title>
|
||||
</info>
|
||||
<para>The <classname>DefaultJaasAuthenticationProvider</classname> allows a JAAS
|
||||
<classname>Configuration</classname> object to be injected into it as a dependency. It then
|
||||
creates a <classname>LoginContext</classname> using the injected JAAS <classname>Configuration</classname>.
|
||||
This means that <classname>DefaultJaasAuthenticationProvider</classname> is not bound any particular implementation
|
||||
of <classname>Configuration</classname> as <classname>JaasAuthenticationProvider</classname> is.</para>
|
||||
|
||||
|
||||
<section xml:id="jaas-inmemoryconfiguration">
|
||||
<info>
|
||||
<title>InMemoryConfiguration</title>
|
||||
</info>
|
||||
<para>In order to make it easy to inject a <classname>Configuration</classname> into
|
||||
<classname>DefaultJaasAuthenticationProvider</classname>, a default in memory
|
||||
implementation named <classname>InMemoryConfiguration</classname> is provided. The
|
||||
implementation constructor accepts a <interfacename>Map</interfacename> where each key represents a
|
||||
login configuration name and the value represents an <classname>Array</classname> of
|
||||
<classname>AppConfigurationEntry</classname>s.
|
||||
<classname>InMemoryConfiguration</classname> also supports a default
|
||||
<classname>Array</classname> of <classname>AppConfigurationEntry</classname> objects that
|
||||
will be used if no mapping is found within the provided <interfacename>Map</interfacename>. For
|
||||
details, refer to the class level javadoc of <classname>InMemoryConfiguration</classname>.</para>
|
||||
<info>
|
||||
<title>InMemoryConfiguration</title>
|
||||
</info>
|
||||
<para>In order to make it easy to inject a <classname>Configuration</classname> into
|
||||
<classname>DefaultJaasAuthenticationProvider</classname>, a default in memory
|
||||
implementation named <classname>InMemoryConfiguration</classname> is provided. The
|
||||
implementation constructor accepts a <interfacename>Map</interfacename> where each key represents a
|
||||
login configuration name and the value represents an <classname>Array</classname> of
|
||||
<classname>AppConfigurationEntry</classname>s.
|
||||
<classname>InMemoryConfiguration</classname> also supports a default
|
||||
<classname>Array</classname> of <classname>AppConfigurationEntry</classname> objects that
|
||||
will be used if no mapping is found within the provided <interfacename>Map</interfacename>. For
|
||||
details, refer to the class level javadoc of <classname>InMemoryConfiguration</classname>.</para>
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="jaas-djap-config">
|
||||
<info>
|
||||
<title>DefaultJaasAuthenticationProvider Example Configuration</title>
|
||||
</info>
|
||||
<para>While the Spring configuration for <classname>InMemoryConfiguration</classname> can be
|
||||
more verbose than the standarad JAAS configuration files, using it in conjuction with
|
||||
<classname>DefaultJaasAuthenticationProvider</classname> is more flexible than
|
||||
<classname>JaasAuthenticationProvider</classname> since it not dependant on the default
|
||||
<classname>Configuration</classname> implementation.</para>
|
||||
<para>An example configuration of <classname>DefaultJaasAuthenticationProvider</classname> using
|
||||
<classname>InMemoryConfiguration</classname> is provided below. Note that custom implementations of
|
||||
<classname>Configuration</classname> can easily be injected into
|
||||
<classname>DefaultJaasAuthenticationProvider</classname> as well.</para>
|
||||
<programlisting><![CDATA[
|
||||
<bean id="jaasAuthProvider"
|
||||
<info>
|
||||
<title>DefaultJaasAuthenticationProvider Example Configuration</title>
|
||||
</info>
|
||||
<para>While the Spring configuration for <classname>InMemoryConfiguration</classname> can be
|
||||
more verbose than the standarad JAAS configuration files, using it in conjuction with
|
||||
<classname>DefaultJaasAuthenticationProvider</classname> is more flexible than
|
||||
<classname>JaasAuthenticationProvider</classname> since it not dependant on the default
|
||||
<classname>Configuration</classname> implementation.</para>
|
||||
<para>An example configuration of <classname>DefaultJaasAuthenticationProvider</classname> using
|
||||
<classname>InMemoryConfiguration</classname> is provided below. Note that custom implementations of
|
||||
<classname>Configuration</classname> can easily be injected into
|
||||
<classname>DefaultJaasAuthenticationProvider</classname> as well.</para>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean id="jaasAuthProvider"
|
||||
class="org.springframework.security.authentication.jaas.DefaultJaasAuthenticationProvider">
|
||||
<property name="configuration">
|
||||
<bean class="org.springframework.security.authentication.jaas.memory.InMemoryConfiguration">
|
||||
<constructor-arg>
|
||||
<map>
|
||||
<!--
|
||||
<!--
|
||||
SPRINGSECURITY is the default loginContextName
|
||||
for AbstractJaasAuthenticationProvider
|
||||
-->
|
||||
|
@ -178,21 +178,21 @@
|
|||
<info>
|
||||
<title>JaasAuthenticationProvider</title>
|
||||
</info>
|
||||
<para>The <classname>JaasAuthenticationProvider</classname> assumes the default <classname>Configuration</classname> is an instance of
|
||||
<para>The <classname>JaasAuthenticationProvider</classname> assumes the default <classname>Configuration</classname> is an instance of
|
||||
<link xlink:href="http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/login/ConfigFile.html">
|
||||
ConfigFile</link>. This assumption is made in order to attempt to update the <classname>Configuration</classname>. The
|
||||
<classname>JaasAuthenticationProvider</classname> then uses the default <classname>Configuration</classname> to create the
|
||||
ConfigFile</link>. This assumption is made in order to attempt to update the <classname>Configuration</classname>. The
|
||||
<classname>JaasAuthenticationProvider</classname> then uses the default <classname>Configuration</classname> to create the
|
||||
<classname>LoginContext</classname>.</para>
|
||||
|
||||
<para>Let’s assume we have a JAAS login configuration file,
|
||||
<literal>/WEB-INF/login.conf</literal>, with the following contents:
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
JAASTest {
|
||||
sample.SampleLoginModule required;
|
||||
};</programlisting></para>
|
||||
<para>Like all Spring Security beans, the <classname>JaasAuthenticationProvider</classname>
|
||||
is configured via the application context. The following definitions would correspond to
|
||||
the above JAAS login configuration file: <programlisting><![CDATA[
|
||||
the above JAAS login configuration file: <programlisting language="xml"><![CDATA[
|
||||
<bean id="jaasAuthenticationProvider"
|
||||
class="org.springframework.security.authentication.jaas.JaasAuthenticationProvider">
|
||||
<property name="loginConfig" value="/WEB-INF/login.conf"/>
|
||||
|
@ -217,14 +217,14 @@ JAASTest {
|
|||
<info>
|
||||
<title xml:id="jaas-api-provision">Running as a Subject</title>
|
||||
</info>
|
||||
<para>If configured, the <classname>JaasApiIntegrationFilter</classname> will attempt to
|
||||
run as the <literal>Subject</literal> on the
|
||||
<classname>JaasAuthenticationToken</classname>. This means that the
|
||||
<literal>Subject</literal> can be accessed using:
|
||||
<para>If configured, the <classname>JaasApiIntegrationFilter</classname> will attempt to
|
||||
run as the <literal>Subject</literal> on the
|
||||
<classname>JaasAuthenticationToken</classname>. This means that the
|
||||
<literal>Subject</literal> can be accessed using:
|
||||
<programlisting language="java"><![CDATA[
|
||||
Subject subject = Subject.getSubject(AccessController.getContext());
|
||||
]]></programlisting>
|
||||
This integration can easily be configured using the
|
||||
This integration can easily be configured using the
|
||||
<link xlink:href="#nsa-jaas-api-provision">jaas-api-provision</link> attribute. This
|
||||
feature is useful when integrating with legacy or external API's that rely on the
|
||||
JAAS Subject being populated.</para>
|
||||
|
|
|
@ -57,7 +57,7 @@
|
|||
<para> The first thing you need to do is configure the server against which authentication
|
||||
should take place. This is done using the <literal><ldap-server></literal> element
|
||||
from the security namespace. This can be configured to point at an external LDAP server,
|
||||
using the <literal>url</literal> attribute: <programlisting><![CDATA[
|
||||
using the <literal>url</literal> attribute: <programlisting language="xml"><![CDATA[
|
||||
<ldap-server url="ldap://springframework.org:389/dc=springframework,dc=org" />
|
||||
]]>
|
||||
</programlisting></para>
|
||||
|
@ -67,7 +67,7 @@
|
|||
</info>
|
||||
<para> The <literal><ldap-server></literal> element can also be used to create an
|
||||
embedded server, which can be very useful for testing and demonstrations. In this
|
||||
case you use it without the <literal>url</literal> attribute: <programlisting><![CDATA[
|
||||
case you use it without the <literal>url</literal> attribute: <programlisting language="xml"><![CDATA[
|
||||
<ldap-server root="dc=springframework,dc=org"/>
|
||||
]]>
|
||||
</programlisting> Here we've specified that the root DIT of the directory should be
|
||||
|
@ -75,7 +75,7 @@
|
|||
namespace parser will create an embedded Apache Directory server and scan the
|
||||
classpath for any LDIF files, which it will attempt to load into the server. You can
|
||||
customize this behaviour using the <literal>ldif</literal> attribute, which defines
|
||||
an LDIF resource to be loaded: <programlisting><![CDATA[
|
||||
an LDIF resource to be loaded: <programlisting language="xml"><![CDATA[
|
||||
<ldap-server ldif="classpath:users.ldif" />
|
||||
]]></programlisting> This makes it a lot easier to get up and running with LDAP, since it
|
||||
can be inconvenient to work all the time with an external server. It also insulates
|
||||
|
@ -88,13 +88,13 @@
|
|||
<info>
|
||||
<title>Using Bind Authentication</title>
|
||||
</info>
|
||||
<para> This is the most common LDAP authentication scenario. <programlisting><![CDATA[
|
||||
<para> This is the most common LDAP authentication scenario. <programlisting language="xml"><![CDATA[
|
||||
<ldap-authentication-provider user-dn-pattern="uid={0},ou=people"/>
|
||||
]]></programlisting> This simple example would obtain the DN for the user by
|
||||
substituting the user login name in the supplied pattern and attempting to bind as
|
||||
that user with the login password. This is OK if all your users are stored under a
|
||||
single node in the directory. If instead you wished to configure an LDAP search
|
||||
filter to locate the user, you could use the following: <programlisting><![CDATA[
|
||||
filter to locate the user, you could use the following: <programlisting language="xml"><![CDATA[
|
||||
<ldap-authentication-provider user-search-filter="(uid={0})"
|
||||
user-search-base="ou=people"/>
|
||||
]]></programlisting> If used with the server definition above, this would
|
||||
|
@ -128,7 +128,7 @@
|
|||
parameter <literal>{1}</literal> can be used if you want to filter on the
|
||||
login name.</para>
|
||||
</listitem>
|
||||
</itemizedlist> So if we used the following configuration <programlisting><![CDATA[
|
||||
</itemizedlist> So if we used the following configuration <programlisting language="xml"><![CDATA[
|
||||
<ldap-authentication-provider user-dn-pattern="uid={0},ou=people"
|
||||
group-search-base="ou=groups" />
|
||||
]]></programlisting> and authenticated successfully as user <quote>ben</quote>, the subsequent
|
||||
|
@ -286,7 +286,7 @@
|
|||
<title>Spring Bean Configuration</title>
|
||||
</info>
|
||||
<para>A typical configuration, using some of the beans we've discussed here, might look
|
||||
like this: <programlisting><![CDATA[
|
||||
like this: <programlisting language="xml"><![CDATA[
|
||||
<bean id="contextSource"
|
||||
class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
|
||||
<constructor-arg value="ldap://monkeymachine:389/dc=springframework,dc=org"/>
|
||||
|
@ -323,7 +323,7 @@
|
|||
from the <quote>ou</quote> attribute of each match.</para>
|
||||
<para>To configure a user search object, which uses the filter
|
||||
<literal>(uid=<user-login-name>)</literal> for use instead of the DN-pattern
|
||||
(or in addition to it), you would configure the following bean <programlisting><![CDATA[
|
||||
(or in addition to it), you would configure the following bean <programlisting language="xml"><![CDATA[
|
||||
<bean id="userSearch"
|
||||
class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
|
||||
<constructor-arg index="0" value=""/>
|
||||
|
@ -348,7 +348,7 @@
|
|||
these will normally be attributes from the user entry. The creation of the
|
||||
<interfacename>UserDetails</interfacename> object is controlled by the provider's
|
||||
<interfacename>UserDetailsContextMapper</interfacename> strategy, which is
|
||||
responsible for mapping user objects to and from LDAP context data: <programlisting><![CDATA[
|
||||
responsible for mapping user objects to and from LDAP context data: <programlisting language="java"><![CDATA[
|
||||
public interface UserDetailsContextMapper {
|
||||
UserDetails mapUserFromContext(DirContextOperations ctx, String username,
|
||||
Collection<GrantedAuthority> authorities);
|
||||
|
|
|
@ -422,7 +422,7 @@
|
|||
Ideally you would want to use a randomly generated salt value for each user, but
|
||||
you can use any property of the <classname>UserDetails</classname> object which
|
||||
is loaded by your <classname>UserDetailsService</classname>. For example, to use
|
||||
the <literal>username</literal> property, you would use <programlisting><![CDATA[
|
||||
the <literal>username</literal> property, you would use <programlisting language="xml"><![CDATA[
|
||||
<password-encoder hash="sha">
|
||||
<salt-source user-property="username"/>
|
||||
</password-encoder>
|
||||
|
@ -461,7 +461,7 @@
|
|||
The available options are "http", "https" or "any". Using the value
|
||||
"any" means that either HTTP or HTTPS can be used. </para>
|
||||
<para>If your application uses non-standard ports for HTTP and/or HTTPS, you can specify
|
||||
a list of port mappings as follows: <programlisting><![CDATA[
|
||||
a list of port mappings as follows: <programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
...
|
||||
<port-mappings>
|
||||
|
@ -501,7 +501,7 @@
|
|||
<literal>JSESSIONID</literal> cookie by expiring it in the response to a
|
||||
logout request (assuming the application is deployed under the path
|
||||
<literal>/tutorial</literal>):
|
||||
<programlisting> <LocationMatch "/tutorial/j_spring_security_logout">
|
||||
<programlisting language="xml"> <LocationMatch "/tutorial/j_spring_security_logout">
|
||||
Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT"
|
||||
</LocationMatch></programlisting></para>
|
||||
</footnote>. </para>
|
||||
|
@ -837,7 +837,7 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
security pointcut declarations which will be applied across your entire application
|
||||
context. You should only declare one
|
||||
<literal><global-method-security></literal> element. The following declaration
|
||||
would enable support for Spring Security's <literal>@Secured</literal>: <programlisting><![CDATA[
|
||||
would enable support for Spring Security's <literal>@Secured</literal>: <programlisting language="xml"><![CDATA[
|
||||
<global-method-security secured-annotations="enabled" />
|
||||
]]>
|
||||
</programlisting> Adding an annotation to a method (on an class or interface) would then limit
|
||||
|
@ -858,12 +858,12 @@ List<OpenIDAttribute> attributes = token.getAttributes();</programlisting>The
|
|||
public Account post(Account account, double amount);
|
||||
}
|
||||
</programlisting>Support
|
||||
for JSR-250 annotations can be enabled using <programlisting><![CDATA[
|
||||
for JSR-250 annotations can be enabled using <programlisting language="xml"><![CDATA[
|
||||
<global-method-security jsr250-annotations="enabled" />
|
||||
]]>
|
||||
</programlisting>These are standards-based and allow simple role-based constraints to
|
||||
be applied but do not have the power Spring Security's native annotations. To use
|
||||
the new expression-based syntax, you would use <programlisting><![CDATA[
|
||||
the new expression-based syntax, you would use <programlisting language="xml"><![CDATA[
|
||||
<global-method-security pre-post-annotations="enabled" />
|
||||
]]></programlisting>and the equivalent Java code would
|
||||
be<programlisting language="java">
|
||||
|
|
|
@ -143,7 +143,7 @@
|
|||
</tip>
|
||||
<section>
|
||||
<title>Siteminder Example Configuration</title>
|
||||
<para> A typical configuration using this filter would look like this: <programlisting><![CDATA[
|
||||
<para> A typical configuration using this filter would look like this: <programlisting language="xml"><![CDATA[
|
||||
<security:http>
|
||||
<!-- Additional http configuration omitted -->
|
||||
<security:custom-filter position="PRE_AUTH_FILTER" ref="siteminderFilter" />
|
||||
|
|
|
@ -26,7 +26,7 @@
|
|||
<para>This approach uses hashing to achieve a useful remember-me strategy. In essence a
|
||||
cookie is sent to the browser upon successful interactive authentication, with the
|
||||
cookie being composed as follows:
|
||||
<programlisting>
|
||||
<programlisting language="txt">
|
||||
base64(username + ":" + expirationTime + ":" +
|
||||
md5Hex(username + ":" + expirationTime + ":" password + ":" + key))
|
||||
|
||||
|
@ -46,7 +46,7 @@
|
|||
section. Alternatively remember-me services should simply not be used at all.</para>
|
||||
<para>If you are familiar with the topics discussed in the chapter on <link
|
||||
xlink:href="#ns-config">namespace configuration</link>, you can enable remember-me
|
||||
authentication just by adding the <literal><remember-me></literal> element: <programlisting><![CDATA[
|
||||
authentication just by adding the <literal><remember-me></literal> element: <programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
...
|
||||
<remember-me key="myAppKey"/>
|
||||
|
@ -68,7 +68,7 @@
|
|||
valid login name unecessarily. There is a discussion on this in the comments section
|
||||
of this article.</para>
|
||||
</footnote>. To use the this approach with namespace configuration, you would supply a
|
||||
datasource reference: <programlisting><![CDATA[
|
||||
datasource reference: <programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
...
|
||||
<remember-me data-source-ref="someDataSource"/>
|
||||
|
@ -77,7 +77,7 @@
|
|||
</programlisting> The database should contain a
|
||||
<literal>persistent_logins</literal> table, created using the following SQL (or
|
||||
equivalent):
|
||||
<programlisting>
|
||||
<programlisting language="ddl">
|
||||
create table persistent_logins (username varchar(64) not null,
|
||||
series varchar(64) primary key,
|
||||
token varchar(64) not null,
|
||||
|
|
|
@ -34,7 +34,7 @@
|
|||
<title>Configuration</title>
|
||||
</info>
|
||||
<para>A <literal>RunAsManager</literal> interface is provided by Spring Security:
|
||||
<programlisting>
|
||||
<programlisting language="java">
|
||||
Authentication buildRunAs(Authentication authentication, Object object,
|
||||
List<ConfigAttribute> config);
|
||||
boolean supports(ConfigAttribute attribute);
|
||||
|
@ -78,7 +78,7 @@
|
|||
<literal>RunAsImplAuthenticationProvider</literal>, the hash of a key is stored in all
|
||||
generated tokens. The <literal>RunAsManagerImpl</literal> and
|
||||
<literal>RunAsImplAuthenticationProvider</literal> is created in the bean context with
|
||||
the same key: <programlisting>
|
||||
the same key: <programlisting language="xml">
|
||||
<![CDATA[
|
||||
<bean id="runAsManager"
|
||||
class="org.springframework.security.access.intercept.RunAsManagerImpl">
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
<title>Explicit MethodSecurityInterceptor Configuration</title>
|
||||
<para> You can of course configure a <classname>MethodSecurityIterceptor</classname>
|
||||
directly in your application context for use with one of Spring AOP's proxying
|
||||
mechanisms: <programlisting><![CDATA[
|
||||
mechanisms: <programlisting language="xml"><![CDATA[
|
||||
<bean id="bankManagerSecurity" class=
|
||||
"org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor">
|
||||
<property name="authenticationManager" ref="authenticationManager"/>
|
||||
|
@ -62,7 +62,7 @@
|
|||
security.</para>
|
||||
<para>Let's first consider how the <literal>AspectJSecurityInterceptor</literal> is
|
||||
configured in the Spring application context:</para>
|
||||
<programlisting><![CDATA[
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean id="bankManagerSecurity" class=
|
||||
"org.springframework.security.access.intercept.aspectj.AspectJSecurityInterceptor">
|
||||
<property name="authenticationManager" ref="authenticationManager"/>
|
||||
|
@ -140,7 +140,7 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean {
|
|||
<para>You will need to configure Spring to load the aspect and wire it with the
|
||||
<literal>AspectJSecurityInterceptor</literal>. A bean declaration which achieves this is
|
||||
shown below:</para>
|
||||
<programlisting><![CDATA[
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean id="domainObjectInstanceSecurityAspect"
|
||||
class="security.samples.aspectj.DomainObjectInstanceSecurityAspect"
|
||||
factory-method="aspectOf">
|
||||
|
|
|
@ -26,7 +26,7 @@
|
|||
and lifecycle interfaces. Spring's <classname>DelegatingFilterProxy</classname> provides
|
||||
the link between <filename>web.xml</filename> and the application context. </para>
|
||||
<para>When using <classname>DelegatingFilterProxy</classname>, you will see something like
|
||||
this in the <filename>web.xml</filename> file: <programlisting><![CDATA[
|
||||
this in the <filename>web.xml</filename> file: <programlisting language="xml"><![CDATA[
|
||||
<filter>
|
||||
<filter-name>myFilter</filter-name>
|
||||
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
|
||||
|
@ -278,7 +278,7 @@
|
|||
most specific patterns must again be declared first. Here's another example, for a similar situation to
|
||||
that above, where the application supports both a stateless RESTful API and also a normal web application
|
||||
which users log into using a form.
|
||||
<programlisting>
|
||||
<programlisting language="xml">
|
||||
<![CDATA[
|
||||
<!-- Stateless RESTful service using Basic authentication -->
|
||||
<http pattern="/restful/**" create-session="stateless">
|
||||
|
@ -323,7 +323,7 @@
|
|||
<para>Now that you've configured the tag libraries, refer to the individual reference guide
|
||||
sections for details on how to use them. Note that when using the tags, you should include
|
||||
the taglib reference in your JSP:
|
||||
<programlisting>
|
||||
<programlisting language="xml">
|
||||
<%@ taglib prefix='security' uri='http://www.springframework.org/security/tags' %>
|
||||
</programlisting></para>
|
||||
</section>
|
||||
|
|
|
@ -40,7 +40,7 @@
|
|||
<classname>AbstractAuthenticationProcessingFilter</classname>, so if you are using a
|
||||
customized form-login class, for example, you will need to inject it into both of these.
|
||||
In this case, a typical configuration, combining the namespace and custom beans might
|
||||
look like this:<programlisting><![CDATA[
|
||||
look like this:<programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
<custom-filter position="FORM_LOGIN_FILTER" ref="myAuthFilter" />
|
||||
<session-management session-authentication-strategy-ref="sas"/>
|
||||
|
@ -90,7 +90,7 @@
|
|||
to have another session open.</para>
|
||||
</note></para>
|
||||
<para>To use concurrent session support, you'll need to add the following to
|
||||
<literal>web.xml</literal>: <programlisting><![CDATA[
|
||||
<literal>web.xml</literal>: <programlisting language="xml"><![CDATA[
|
||||
<listener>
|
||||
<listener-class>
|
||||
org.springframework.security.web.session.HttpSessionEventPublisher
|
||||
|
@ -104,7 +104,7 @@
|
|||
<classname>SessionRegistryImpl</classname>, and <literal>expiredUrl</literal>, which
|
||||
points to the page to display when a session has expired. A configuration using the
|
||||
namespace to create the <classname>FilterChainProxy</classname> and other default beans
|
||||
might look like this: <programlisting><![CDATA[
|
||||
might look like this: <programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
<custom-filter position="CONCURRENT_SESSION_FILTER" ref="concurrencyFilter" />
|
||||
<custom-filter position="FORM_LOGIN_FILTER" ref="myAuthFilter" />
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<section>
|
||||
<title>Declaring the Taglib</title>
|
||||
<para>To use any of the tags, you must have the security taglib declared in your JSP:
|
||||
<programlisting>
|
||||
<programlisting language="xml">
|
||||
<![CDATA[<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>]]>
|
||||
</programlisting></para>
|
||||
</section>
|
||||
|
@ -23,7 +23,7 @@
|
|||
context (you should have web expressions enabled in your <literal><http></literal>
|
||||
namespace configuration to make sure this service is available). So, for example, you
|
||||
might
|
||||
have<programlisting><sec:authorize access="hasRole('supervisor')">
|
||||
have<programlisting language="xml"><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.
|
||||
|
@ -34,7 +34,7 @@ the "supervisor" authority in their list of <tt>GrantedAuthority</tt>s.
|
|||
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<programlisting><sec:authorize url="/admin">
|
||||
like<programlisting language="xml"><sec:authorize url="/admin">
|
||||
|
||||
This content will only be visible to users who are authorized to send requests to the "/admin" URL.
|
||||
|
||||
|
@ -94,7 +94,7 @@ This content will only be visible to users who are authorized to send requests t
|
|||
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<programlisting><sec:accesscontrollist hasPermission="1,2" domainObject="someObject">
|
||||
be<programlisting language="xml"><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.
|
||||
|
|
|
@ -294,7 +294,7 @@ class SampleAuthenticationManager implements AuthenticationManager {
|
|||
<interfacename>AuthenticationManager</interfacename> which we've implemented here
|
||||
will authenticate any user whose username and password are the same. It assigns a
|
||||
single role to every user. The output from the above will be something
|
||||
like:<programlisting>
|
||||
like:<programlisting language="txt">
|
||||
Please enter your username:
|
||||
bob
|
||||
Please enter your password:
|
||||
|
@ -668,7 +668,7 @@ Successfully authenticated. Security context contains: \
|
|||
register a bean inside your application context to refer to the messages. An example is
|
||||
shown below:</para>
|
||||
<para>
|
||||
<programlisting><![CDATA[
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<bean id="messageSource"
|
||||
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
|
||||
<property name="basename" value="classpath:org/springframework/security/messages"/>
|
||||
|
|
|
@ -36,13 +36,13 @@
|
|||
|
||||
<para> Enabling X.509 client authentication is very straightforward. Just add the
|
||||
<literal><x509/></literal> element to your http security namespace configuration.
|
||||
<programlisting>
|
||||
<http>
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<http>
|
||||
...
|
||||
<x509 subject-principal-regex="CN=(.*?)," user-service-ref="userService"/>
|
||||
<x509 subject-principal-regex="CN=(.*?)," user-service-ref="userService"/>;
|
||||
...
|
||||
</http>
|
||||
</programlisting>
|
||||
</http>
|
||||
]]></programlisting>
|
||||
The element has two optional attributes: <itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>subject-principal-regex</literal>. The regular expression used to
|
||||
|
@ -82,15 +82,15 @@
|
|||
<para> To run tomcat with SSL support, drop the <filename>server.jks</filename> file into
|
||||
the tomcat <filename>conf</filename> directory and add the following connector to the
|
||||
<filename>server.xml</filename> file
|
||||
<programlisting>
|
||||
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" scheme="https" secure="true"
|
||||
<programlisting language="xml"><![CDATA[
|
||||
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" scheme="https" secure="true"
|
||||
clientAuth="true" sslProtocol="TLS"
|
||||
keystoreFile="${catalina.home}/conf/server.jks"
|
||||
keystoreType="JKS" keystorePass="password"
|
||||
truststoreFile="${catalina.home}/conf/server.jks"
|
||||
truststoreType="JKS" truststorePass="password"
|
||||
/>
|
||||
</programlisting>
|
||||
/>
|
||||
]]></programlisting>
|
||||
<parameter>clientAuth</parameter> can also be set to <parameter>want</parameter> if you
|
||||
still want SSL connections to succeed even if the client doesn't provide a certificate.
|
||||
Clients which don't present a certificate won't be able to access any objects secured by
|
||||
|
|
Loading…
Reference in New Issue