Authorizers: (v4.2)
Authorizers are meant to check authorizations when accessing an URL (in the “security filter”):
- either on the authenticated user profile: has the user the appropriate role?
- or on the web context: can you call this resource with that HTTP method?
Notice that this concept of Authorizer
has a broader meaning than generally in the security field.
Generally, authorizers are defined in the security configuration of the application.
Various authorizers are available:
- Roles/permissions - Anonymous/remember-me/(fully) authenticated - Profile type, attribute
- CSRF - IP address, HTTP method
▸ Default authorizer names
Most pac4j implementations use the pac4j logics and authorizers and thus the DefaultAuthorizationChecker
component. In that case, the following authorizers are automatically available via the following short keywords:
csrfCheck
(for theCsrfAuthorizer
authorizer) to check that the CSRF token has been sent as thepac4jCsrfToken
header or parameter in a POST requestisAnonymous
(for theIsAnonymousAuthorizer
authorizer) to ensure the user is not authenticatedisAuthenticated
(for theIsAuthenticatedAuthorizer
authorizer) to ensure the user is authenticated (not necessary by default unless you use theAnonymousClient
)isFullyAuthenticated
(for theIsFullyAuthenticatedAuthorizer
authorizer) to check if the user is authenticated but not rememberedisRemembered
(for theIsRememberedAuthorizer
authorizer) for a remembered usernone
for no authorizers at all.
These short names are defined as constants in DefaultAuthorizers
.
▸ The composition of authorizers
You can create a composition (conjunction or disjunction) of authorizers. For example:
final Authorizer<CommonProfile> authorizer = or(
and(
requireAnyRole("profile_role1"),
requireAnyPermission("profile_permission1")
),
and(
requireAnyRole("profile_role2"),
requireAnyPermission("profile_permission2")
)
);