Security filter: (v4.3)
In order to secure an URL, the pac4j implementation provides the security filter which delegates the work to the
DefaultSecurityLogic has the following behaviour:
If the HTTP request matches the matchers configuration (or no matchers are defined), the security is applied. Otherwise, the user is automatically granted access.
First, if the user is not authenticated (no profile) and if some clients have been defined in the clients parameter, a login is tried for the direct clients.
Then, if the user has a profile, authorizations are checked according to the authorizers configuration. If the authorizations are valid, the user is granted access. Otherwise, a 403 error page is displayed.
Finally, if the user is not authenticated (no profile), he is redirected to the appropriate identity provider if the first defined client is an indirect one in the clients configuration. Otherwise, a 401 error page is displayed.
The following options are available:
It’s the security configuration.
It’s a string of the list of the client names (separated by commas) used for authentication. It is an optional parameter.
In all cases, this filter requires the user to be authenticated. Thus, if the
clients is blank or not defined, the user must have been previously authenticated or a 401 error is returned.
A specific client may be chosen among all defined clients for the filter by using the request parameter:
It’s a string of the list of the authorizer names (separated by commas) used to check authorizations. It is an optional parameter.
authorizers is blank or not defined, the default authorizer is applied:
csrfCheck for web applications and no authorizer is applied for web services.
You can also use the out-of-the-box authorizers, already available without defining them in the security configuration.
It’s the list of the matcher names (separated by commas) that the request must satisfy to check authentication/authorizations. It is an optional parameter.
matchers is blank or not defined, it is satisfied and the
securityHeaders,csrfToken matchers are applied for web applications or the
securityHeaders matcher is applied for web services.
You can also use the out-of-the-box matchers, already available without defining them in the security configuration.
It indicates whether multiple authentications (and thus multiple profiles) must be kept at the same time. It is an optional parameter,
false by default.
DefaultSecurityLogic component, you can set the
ProfileStorageDecision which defines the decisions related to the profiles, whether we must read them from and save them into the web session if retrieved by a direct client: