Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


If you've ever wondered how to make a cookie-based rememberMe more secure, you should read the "Persistent login cookie best practice" blog post. One-time usable, per-IP issued access tokens are as secure as an intentional security hole will get. You might wonder what this has to do with federated accounts but tynamo-federatedaccounts-rollingtokens module well showcases the flexibility of the federatedaccounts core: a rollingtokens realm is treated as just another third-party authentication provider, handling issuing random access tokens and validating them against a persistent, server-side records before passing the control to your local realm. The rollingtokens module also utilizes the more esoteric Shiro/tapestry-security features such as a login listeners and a custom subject factory. Currently tynamo-federatedaccounts-rollingtokens module includes a JPA only implementation, sorry (we may include a Hibernate implementation if there's enough demand). To use the feature, add the following to your pom.xml:

Code Block
    // dependencies in your pom.xml 


	public static void contributeFederatedAccountService(MappedConfiguration<String, Object> configuration) {
        configuration.add("rollingtokens", UserAccount.class);
        configuration.add("rollingtokens" + FederatedAccountService.IDPROPERTY, "id");

	// Need to tell principal type to rolling tokens so it can be persisted properly with the ExpiringRollingToken
    public static void contributeApplicationDefaults(MappedConfiguration<String, String> configuration) {
        configuration.add(RollingTokenSymbols.CONFIGURED_PRINCIPALTYPE, Long.class.getName());

	// rollingtokens is currently JPA only
    public static void addPackagesToScan(Configuration<String> configuration) {

Rollingtoken plays especially well with Shiro's built-in rememberMe and Subject.authenticated feature. In Shiro's default rememberMe a Subject "is remembered, they are NOT considered authenticated". Together with rollingtokens, two cookies are issued to the user. If the matching principal is found but rollingtoken authentication fails, Subject.isAuthenticated() returns false and true if matching server-side token was found and hadn't expired, just as if user had signed in with a username/password pair. Note however, that rollingtokens does weaken the security compared to secure form-based authentication (but is in some ways more secure than BASIC or form-based authentication over plain HTTP).