Fork me on GitHub

Customizations: (v6.0)

pac4j comes with a huge set of components for various needs, so before any customization, you should carefully read the Clients, Authenticators and Authorizers pages to check what is already provided.

Customizing the authentication/authorization components:

Be sure to clearly understand what the roles of the different components are:

Overriding or creating new components should be straightforward.

Nonetheless, building a Client requires extra efforts. Notice that:

Changing the core flow:

Overriding or creating new components allows you to implement new behaviour inside the boundaries of the defined logics of the regular pac4j “filters”. Though, in some cases, it may not be enough. So you may decide to break the flow and change the provided behaviour by requesting some extra actions. And this can be done by throwing an HttpAction (like any exception) as most components allow that.

Example:

public class ExampleAuthorizer implements Authorizer<CommonProfile> {

    @Override
    public boolean isAuthorized(WebContext context, List<CommonProfile> profiles) throws HttpAction {
        if ("specificValue".equals(context.getRequestHeader("specificHeader")))
        {
            throw HttpAction.redirect("force redirection", context, "/message.html");
        }
        return true;
    }
}

Customizing the web integration

pac4j implementations heavily rely on the WebContext and SessionStore to deal with the HTTP request, response and session. The default implementations of theses component may be override or replaced.

As well as the default ProfileManager (used to save/restore the profile) or GuavaStore (to save data in cache).

In all cases, there is nothing better than taking a look at the existing components as examples. Don’t hesitate to ask any question on the pac4j-dev mailing list.