parent
fb5776cb5c
commit
933a7e8363
|
@ -43,7 +43,7 @@ interface Filterer<T> extends Iterable<T> {
|
|||
Iterator<T> iterator();
|
||||
|
||||
/**
|
||||
* Removes the the given object from the resulting list.
|
||||
* Removes the given object from the resulting list.
|
||||
*
|
||||
* @param object the object to be removed
|
||||
*/
|
||||
|
|
|
@ -27,7 +27,7 @@ import java.util.List;
|
|||
public interface PermissionGrantingStrategy {
|
||||
|
||||
/**
|
||||
* Returns true if the the supplied strategy decides that the supplied {@code Acl}
|
||||
* Returns true if the supplied strategy decides that the supplied {@code Acl}
|
||||
* grants access based on the supplied list of permissions and sids.
|
||||
*/
|
||||
boolean isGranted(Acl acl, List<Permission> permission, List<Sid> sids,
|
||||
|
|
|
@ -91,7 +91,7 @@ public interface StatelessTicketCache {
|
|||
*
|
||||
* <P>
|
||||
* Implementations should use {@link CasAuthenticationToken#getCredentials()} to
|
||||
* obtain the ticket and then delegate to to the
|
||||
* obtain the ticket and then delegate to the
|
||||
* {@link #removeTicketFromCache(String)} method.
|
||||
* </p>
|
||||
*
|
||||
|
|
|
@ -63,7 +63,7 @@ abstract class AbstractDaoAuthenticationConfigurer<B extends ProviderManagerBuil
|
|||
|
||||
/**
|
||||
* Allows specifying the {@link PasswordEncoder} to use with the
|
||||
* {@link DaoAuthenticationProvider}. The default is is to use plain text.
|
||||
* {@link DaoAuthenticationProvider}. The default is to use plain text.
|
||||
*
|
||||
* @param passwordEncoder The {@link PasswordEncoder} to use.
|
||||
* @return
|
||||
|
@ -77,7 +77,7 @@ abstract class AbstractDaoAuthenticationConfigurer<B extends ProviderManagerBuil
|
|||
/**
|
||||
* Allows specifying the
|
||||
* {@link org.springframework.security.authentication.encoding.PasswordEncoder} to use
|
||||
* with the {@link DaoAuthenticationProvider}. The default is is to use plain text.
|
||||
* with the {@link DaoAuthenticationProvider}. The default is to use plain text.
|
||||
*
|
||||
* @param passwordEncoder The
|
||||
* {@link org.springframework.security.authentication.encoding.PasswordEncoder} to
|
||||
|
|
|
@ -413,7 +413,7 @@ public final class HttpSecurity extends
|
|||
}
|
||||
|
||||
/**
|
||||
* Configures container based based pre authentication. In this case, authentication
|
||||
* Configures container based pre authentication. In this case, authentication
|
||||
* is managed by the Servlet Container.
|
||||
*
|
||||
* <h2>Example Configuration</h2>
|
||||
|
|
|
@ -27,7 +27,7 @@ import javax.security.auth.callback.UnsupportedCallbackException;
|
|||
* The JaasAuthenticationCallbackHandler is similar to the
|
||||
* javax.security.auth.callback.CallbackHandler interface in that it defines a handle
|
||||
* method. The JaasAuthenticationCallbackHandler is only asked to handle one Callback
|
||||
* instance at at time rather than an array of all Callbacks, as the javax...
|
||||
* instance at time rather than an array of all Callbacks, as the javax...
|
||||
* CallbackHandler defines.
|
||||
*
|
||||
* <p>
|
||||
|
|
|
@ -175,7 +175,7 @@ Session management issues are a common source of forum questions. If you are dev
|
|||
[[appendix-faq-concurrent-session-same-browser]]
|
||||
==== I'm using Spring Security's concurrent session control to prevent users from logging in more than once at a time. When I open another browser window after logging in, it doesn't stop me from logging in again. Why can I log in more than once?
|
||||
|
||||
Browsers generally maintain a single session per browser instance. You cannot have two separate sessions at once. So if you log in again in another window or tab you are just reauthenticating in the same session. The server doesn't know anything about tabs, windows or browser instances. All it sees are HTTP requests and it ties those to a particular session according to the value of the the JSESSIONID cookie that they contain. When a user authenticates during a session, Spring Security's concurrent session control checks the number of__other authenticated sessions__ that they have. If they are already authenticated with the same session, then re-authenticating will have no effect.
|
||||
Browsers generally maintain a single session per browser instance. You cannot have two separate sessions at once. So if you log in again in another window or tab you are just reauthenticating in the same session. The server doesn't know anything about tabs, windows or browser instances. All it sees are HTTP requests and it ties those to a particular session according to the value of the JSESSIONID cookie that they contain. When a user authenticates during a session, Spring Security's concurrent session control checks the number of__other authenticated sessions__ that they have. If they are already authenticated with the same session, then re-authenticating will have no effect.
|
||||
|
||||
|
||||
[[appendix-faq-new-session-on-authentication]]
|
||||
|
|
|
@ -181,7 +181,7 @@ It is important to note that Spring Security only secures the `clientInboundChan
|
|||
Spring Security does not attempt to secure the `clientOutboundChannel`.
|
||||
|
||||
The most important reason for this is performance.
|
||||
For every message that goes in, there are typically many many more that go out.
|
||||
For every message that goes in, there are typically many more that go out.
|
||||
Instead of securing the outbound messages, we encourage securing the subscription to the endpoints.
|
||||
|
||||
[[websocket-sameorigin]]
|
||||
|
|
|
@ -1948,7 +1948,7 @@ This design offers maximum deployment time flexibility, as you can simply copy y
|
|||
|
||||
[[core-components]]
|
||||
=== Core Components
|
||||
In Spring Security 3.0, the contents of the `spring-security-core` jar were stripped down to the bare minimum. It no longer contains any code related to web-application security, LDAP or namespace configuration. We'll take a look here at some of the Java types that you'll find in the core module. They represent the building blocks of the the framework, so if you ever need to go beyond a simple namespace configuration then it's important that you understand what they are, even if you don't actually need to interact with them directly.
|
||||
In Spring Security 3.0, the contents of the `spring-security-core` jar were stripped down to the bare minimum. It no longer contains any code related to web-application security, LDAP or namespace configuration. We'll take a look here at some of the Java types that you'll find in the core module. They represent the building blocks of the framework, so if you ever need to go beyond a simple namespace configuration then it's important that you understand what they are, even if you don't actually need to interact with them directly.
|
||||
|
||||
|
||||
==== SecurityContextHolder, SecurityContext and Authentication Objects
|
||||
|
@ -2237,7 +2237,7 @@ Only developers contemplating an entirely new way of intercepting and authorizin
|
|||
|
||||
[[localization]]
|
||||
=== Localization
|
||||
Spring Security supports localization of exception messages that end users are likely to see. If your application is designed for English-speaking users, you don't need to do anything as by default all Security Security messages are in English. If you need to support other locales, everything you need to know is contained in this section.
|
||||
Spring Security supports localization of exception messages that end users are likely to see. If your application is designed for English-speaking users, you don't need to do anything as by default all Security messages are in English. If you need to support other locales, everything you need to know is contained in this section.
|
||||
|
||||
All exception messages can be localized, including messages related to authentication failures and access being denied (authorization failures). Exceptions and logging messages that are focused on developers or system deployers (including incorrect attributes, interface contract violations, using incorrect constructors, startup time validation, debug-level logging) are not localized and instead are hard-coded in English within Spring Security's code.
|
||||
|
||||
|
@ -2413,7 +2413,7 @@ Bcrypt automatically generates a random salt value for each password when it is
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
The legacy approach to handling salt was to inject a `SaltSource` into the `DaoAuthenticationProvider`, which would obtain a salt value for a particular user and pass it to the `PasswordEncoder`. Using bcrypt means you don't have worry about the details of salt handling (such as where the the value is stored), as it is all done internally. So we'd strongly recommend you use bcrypt unless you already have a system in place which stores the salt separately.
|
||||
The legacy approach to handling salt was to inject a `SaltSource` into the `DaoAuthenticationProvider`, which would obtain a salt value for a particular user and pass it to the `PasswordEncoder`. Using bcrypt means you don't have worry about the details of salt handling (such as where the value is stored), as it is all done internally. So we'd strongly recommend you use bcrypt unless you already have a system in place which stores the salt separately.
|
||||
====
|
||||
|
||||
==== Hashing and Authentication
|
||||
|
@ -2764,7 +2764,7 @@ It should be noted that it is typically bad practice to perform so much logic th
|
|||
|
||||
[[servletapi-user-in-role]]
|
||||
==== HttpServletRequest.isUserInRole(String)
|
||||
The http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#isUserInRole(java.lang.String)[HttpServletRequest.isUserInRole(String)] will determine if `SecurityContextHolder.getContext().getAuthentication().getAuthorities()` contains a `GrantedAuthority` with the role passed into `isUserInRole(String)`. Typically users should not pass in the "ROLE_" prefix into this method since it is added automatically. For example, if you want to determine if the current user has the authority "ROLE_ADMIN", you could use the the following:
|
||||
The http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#isUserInRole(java.lang.String)[HttpServletRequest.isUserInRole(String)] will determine if `SecurityContextHolder.getContext().getAuthentication().getAuthorities()` contains a `GrantedAuthority` with the role passed into `isUserInRole(String)`. Typically users should not pass in the "ROLE_" prefix into this method since it is added automatically. For example, if you want to determine if the current user has the authority "ROLE_ADMIN", you could use the following:
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
@ -6079,7 +6079,7 @@ The next step is to update the `CasAuthenticationProvider` to be able to obtain
|
|||
</bean>
|
||||
----
|
||||
|
||||
The last step is to update the `CasAuthenticationFilter` to accept PGT and to store them in the `ProxyGrantingTicketStorage`. It is important the the `proxyReceptorUrl` matches the `proxyCallbackUrl` of the `Cas20ProxyTicketValidator`. An example configuration is shown below.
|
||||
The last step is to update the `CasAuthenticationFilter` to accept PGT and to store them in the `ProxyGrantingTicketStorage`. It is important the `proxyReceptorUrl` matches the `proxyCallbackUrl` of the `Cas20ProxyTicketValidator`. An example configuration is shown below.
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
@ -58,7 +58,7 @@ public class OpenIDAuthenticationToken extends AbstractAuthenticationToken {
|
|||
/**
|
||||
* Created by the <tt>OpenIDAuthenticationProvider</tt> on successful authentication.
|
||||
*
|
||||
* @param principal usually the <tt>UserDetails</tt> returned by the the configured
|
||||
* @param principal usually the <tt>UserDetails</tt> returned by the configured
|
||||
* <tt>UserDetailsService</tt> used by the <tt>OpenIDAuthenticationProvider</tt>.
|
||||
*
|
||||
*/
|
||||
|
|
|
@ -50,7 +50,7 @@ public final class ProxyTicketSampleServlet extends HttpServlet {
|
|||
// SecurityContextHolder.getContext().getAuthentication()
|
||||
final CasAuthenticationToken token = (CasAuthenticationToken) request
|
||||
.getUserPrincipal();
|
||||
// proxyTicket could be reused to make calls to to the CAS service even if the
|
||||
// proxyTicket could be reused to make calls to the CAS service even if the
|
||||
// target url differs
|
||||
final String proxyTicket = token.getAssertion().getPrincipal()
|
||||
.getProxyTicketFor(targetUrl);
|
||||
|
|
|
@ -21,7 +21,7 @@ import java.util.regex.Pattern;
|
|||
|
||||
/**
|
||||
* Implementation which uses a regular expression to validate the supplied origin. If the
|
||||
* value of the HTTP parameter matches the pattern, then the the result will be ALLOW-FROM
|
||||
* value of the HTTP parameter matches the pattern, then the result will be ALLOW-FROM
|
||||
* <paramter-value>.
|
||||
*
|
||||
* @author Marten Deinum
|
||||
|
|
Loading…
Reference in New Issue