|
@@ -1948,7 +1948,7 @@ This design offers maximum deployment time flexibility, as you can simply copy y
|
|
|
|
|
|
[[core-components]]
|
|
[[core-components]]
|
|
=== 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
|
|
==== SecurityContextHolder, SecurityContext and Authentication Objects
|
|
@@ -2237,7 +2237,7 @@ Only developers contemplating an entirely new way of intercepting and authorizin
|
|
|
|
|
|
[[localization]]
|
|
[[localization]]
|
|
=== 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.
|
|
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]
|
|
[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
|
|
==== 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]]
|
|
[[servletapi-user-in-role]]
|
|
==== HttpServletRequest.isUserInRole(String)
|
|
==== 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]
|
|
[source,java]
|
|
----
|
|
----
|
|
@@ -6079,7 +6079,7 @@ The next step is to update the `CasAuthenticationProvider` to be able to obtain
|
|
</bean>
|
|
</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]
|
|
[source,xml]
|
|
----
|
|
----
|