You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/servlet/appendix/faq.adoc
+75-39Lines changed: 75 additions & 39 deletions
Original file line number
Diff line number
Diff line change
@@ -519,73 +519,109 @@ A security-conscious organization should be aware that the benefits of their dil
519
519
If you have taken this into account (perhaps by using multiple layers of security within your application), Spring Security lets you fully customize the source of security metadata.
520
520
You can make it fully dynamic if you choose.
521
521
522
-
Both method and web security are protected by subclasses of `AbstractSecurityInterceptor`, which is configured with a `SecurityMetadataSource` from which it obtains the metadata for a particular method or filter invocation.
523
-
For web security, the interceptor class is `FilterSecurityInterceptor`, and it uses the `FilterInvocationSecurityMetadataSource` marker interface. The "`secured object`" type it operates on is a `FilterInvocation`. The default implementation (which is used both in the namespace `<http>` and when configuring the interceptor explicitly) stores the list of URL patterns and their corresponding list of "`configuration attributes`" (instances of `ConfigAttribute`) in an in-memory map.
524
-
525
-
To load the data from an alternative source, you must use an explicitly declared security filter chain (typically Spring Security's `FilterChainProxy`) to customize the `FilterSecurityInterceptor` bean.
526
-
You cannot use the namespace.
527
-
You would then implement `FilterInvocationSecurityMetadataSource` to load the data as you please for a particular `FilterInvocation`. The `FilterInvocation` object contains the `HttpServletRequest`, so you can obtain the URL or any other relevant information on which to base your decision, based on what the list of returned attributes contains. A basic outline would look something like the following example:
522
+
Both method and web security are protected by implementations of `AuthorizationManager`.
523
+
For web security, you can supply your own implementation of `AuthorizationManager<RequestAuthorizationContext>` and supply it to the filter chain DSL like so:
528
524
529
525
[tabs]
530
526
======
531
527
Java::
532
528
+
533
529
[source,java,role="primary"]
534
530
----
531
+
@Component
532
+
public class DynamicAuthorizationManager implements AuthorizationManager<RequestAuthorizationContext> {
533
+
private final MyExternalAuthorizationService authz;
535
534
536
-
public class MyFilterSecurityMetadataSource implements FilterInvocationSecurityMetadataSource {
535
+
// ...
537
536
538
-
public List<ConfigAttribute> getAttributes(Object object) {
539
-
FilterInvocation fi = (FilterInvocation) object;
540
-
String url = fi.getRequestUrl();
541
-
String httpMethod = fi.getRequest().getMethod();
542
-
List<ConfigAttribute> attributes = new ArrayList<ConfigAttribute>();
537
+
@Override
538
+
public AuthorizationDecision check(Supplier<Authentication> authentication, RequestAuthorizationContext context) {
539
+
// query the external service
540
+
}
541
+
}
543
542
544
-
// Lookup your database (or other source) using this information and populate the
0 commit comments