-
-
Notifications
You must be signed in to change notification settings - Fork 202
Description
Hi,
pac4j v1.9.1 is out and Jooby should upgrade to use it.
The source code has been cleaned (-15% in size), dependencies (Java 8 also) have been upgraded, multi-profiles are supported and extension capabilities are much better -> https://github.com/pac4j/pac4j/wiki/Versions
Keeping the current Jooby security algorithms and upgrading to pac4j v1.9.1 should be straightforward (most API signatures have remained the same). This is your option number 1: really easy!
Though, pac4j has reached a strong maturity with version 1.9: the security model is now available via specific components (and not only guidelines).
In addition to the concepts: clients, authorizers and matchers (whether to apply security or not), you now have three "filters":
- The "security filter" (or whatever the mechanism used to intercept HTTP requests) protects an url by checking that the user is authenticated and that the authorizations are valid, according to the clients and authorizers configuration. If the user is not authenticated, it performs authentication for direct clients or starts the login process for indirect clients
- The "callback controller" finishes the login process for an indirect client
- The application logout controller" logs out the user from the application.
For example, for the "security filter", its logic is available via the DefaultSecurityLogic which makes implementations very easy:
- In J2E:
@Override
protected final void internalFilter(final HttpServletRequest request, final HttpServletResponse response,
final FilterChain filterChain) throws IOException, ServletException {
assertNotNull("securityLogic", securityLogic);
final Config config = getConfig();
assertNotNull("config", config);
final J2EContext context = new J2EContext(request, response, config.getSessionStore());
securityLogic.perform(context, config, (ctx, parameters) -> {
filterChain.doFilter(request, response);
return null;
}, J2ENopHttpActionAdapter.INSTANCE, clients, authorizers, matchers, multiProfile);
}- In Play:
public CompletionStage<Result> internalCall(final Context ctx, final String clients, final String authorizers, final boolean multiProfile) throws Throwable {
assertNotNull("config", config);
final PlayWebContext playWebContext = new PlayWebContext(ctx, sessionStore);
final HttpActionAdapterWrapper actionAdapterWrapper = new HttpActionAdapterWrapper(config.getHttpActionAdapter());
return securityLogic.perform(playWebContext, config, (webCtx, parameters) -> {
// when called from Scala
if (delegate == null) {
return CompletableFuture.completedFuture(null);
} else {
return delegate.call(ctx);
}
}, actionAdapterWrapper, clients, authorizers, null, multiProfile, ctx);
}And the ProfileManager is the component to use to get the current authenticated user while the SessionStore is the abstraction for the web session.
The short guide: https://github.com/pac4j/pac4j/wiki/How-to-implement-pac4j-for-a-new-framework---tool
So this is your option number 2: a lot more work, but a lot more powerful: multiple clients / authorizers definitions, multi profiles authenticated at the same time...
What do you think?
Thanks.
Best regards,
Jérôme