Authenticators: (v6.1)
HTTP clients require an Authenticator
to validate the credentials.
This Authenticator
interface has only one method: Optional<Credentials> validate(CallContext ctx, Credentials credentials)
.
Credentials
can be of two kinds:
- username/password are
UsernamePasswordCredentials
- tokens or identifiers are
TokenCredentials
.
The HttpAction
allows you to interrupt the credentials validation and trigger a specific HTTP action (like a temporary redirection).
You can use various Authenticator
for many identity mechanisms:
1) Dealing with performance issues
For direct HTTP clients, credentials are passed and validated for each request, which may lead to performance issues (too many calls to the underlying identity system). So the use of a cache is highly recommended.
This can be done using the LocalCachingAuthenticator
class (available in the pac4j-core
module) which caches the resulted user profile depending on the provided credentials and can thus spare credentials validation on the identity system.
Example:
LocalCachingAuthenticator authent = new LocalCachingAuthenticator(new JwtAuthenticator(secret), 10000, 15, TimeUnit.MINUTES);
By default, the LocalCachingAuthenticator
uses Guava as its internal Store
but you can provide your own store via the setStore
method.
LocalCachingAuthenticator
requires the additionnal guava dependency.In some cases, you may also rely on the session by using: client.setSaveProfileInSession(true);
.
In case of a “noop” authenticator (Authenticator.ALWAYS_VALIDATE
) where only the profile creation matters, you should use the LocalCachingProfileCreator
instead.
2) PasswordEncoder
Regarding the IP address authenticator, there is no need for password protection. Regarding the LDAP authenticator, the password protection is handled by the system itself.
But for the MongoDB and SQL authenticators, the password protection must be handled explicitly by the PasswordEncoder
which can encode plaintext passwords into encrypted passwords as well as check if a plaintext password matches with an already encoded password.
The password encoder must be defined for these two authenticators via constructors or via the setPasswordEncoder(passwordEncoder)
method.
Three PasswordEncoder
implementations are available:
- a wrapper for the Spring Security Crypto
PasswordEncoder
: theSpringSecurityPasswordEncoder
- a wrapper for the Apache Shiro
PasswordService
: theShiroPasswordEncoder
- one based on the jBCrypt library: the
JBCryptPasswordEncoder
.
SpringSecurityPasswordEncoder
requires the additionnal spring-security-crypto dependency, the ShiroPasswordEncoder
the shiro-core dependency and the JBCryptPasswordEncoder
the jBCrypt dependency.3) ProfileCreator
In fact, in the HTTP clients, you can also define the way the user profile is created via a ProfileCreator
in addition to the way of validating credentials (Authenticator
).
In practice:
- all the available
Authenticator
create a specific user profile when validating credentials and save it in the currentCredentials
- all the clients are configured by default with the
AuthenticatorProfileCreator
which retrieves the user profile from the currentCredentials
and returns it.
So it works out of the box, even if providing a specific ProfileCreator
is possible.