Categories
Security

Release Octopus v0.9.7

Introduction

I’m happy to announce the latest version of the Java EE Security framework Octopus, version 0.9.7.

After more than a year of development and testing and 2 projects where the major new features are already used, we feel it is time to release a final version of the framework.

The theme of this release is Self-Contained Systems. (Only for Java EE 7+)

  • Octopus SSO server compatible with OpenIdConnect protocol.
  • Transfer authentication and permission information within the header of JAX-RS rest calls.
  • Support of String based permissions.

But there are other important new features like

  • Support for RBAC – Role Based Access Control.
  • Implementing OWASP recommendations about Session management.
  • Support for 2-step authentication with OTP (One-time password)
  • Possibility to create a more advanced (then a custom voter) security annotation.
  • Initial support for Java SE

Self-Contained System support

Octopus SSO Server

in this announcement, I want you to tell something more about the support for Self-Contained Systems (SCS).

You can see them as a variant of microServices, the important feature about an SCS is that it is responsible for the data of a certain domain (like products or orders) and that it contains all the business logic and UI to work with the data.

Interaction, preferable asynchronously, with other SCS goes through the UI of them since Web pages and REST endpoints are both considered as UI.

The image shows these basic features of an SCS.

For an excellent introduction, I can recommend the site http://scs-architecture.org/

With this latest release of Octopus, implementing security within an SCS architecture becomes quite easy.

With the Octopus SSO server, you can turn one of the SCS in charge of the security.Based on the OpenIdConnect protocol, another SCS (clients) can delegate the authentication process to the Octopus SSO server. An additional scope, ‘Octopus’ makes it possible that the permissions of the authenticated user are transferred to the client.

Based on the OpenIdConnect protocol, another SCS (clients) can delegate the authentication process to the Octopus SSO server. An additional scope, ‘Octopus’ makes it possible that the permissions of the authenticated user are transferred to the client.

The image below gives an idea how it works (Authorisation grant flow)

The maven artefacts that one can use for this feature are
be.c4j.ee.security.octopus.sso:octopus-server and be.c4j.ee.security.octopus.sso:octopus-client

Because permissions need to be transferred from one SCS to another, it becomes easier if these permissions are just Strings. Although a more type-safe approach like enum values, here String are more pragmatic. (example further in text)

JAX-RS communication between SCS

Also, the communication with a JAX-RS endpoint can easily be secured with the SCS user modules.

The idea is that the information of the currently authenticated user is packed within a JWT and send in the header of the REST call. The server endpoint uses this info from the header, to recreate the principal and his permissions.

The normal Octopus security annotations, like @RequiredUser or @OctopusPermissions(“order:read:*”) can be used on the server side (containing the JAX-RS endpoint)
When the calling user doesn’t have the permission “order:read:*”, automatically a status 403 is returned.

On the server side, you can have something like this

@Path("/user")
public class UserController {

   @GET
   @OctopusPermissions("User:Read:*")
   public List<User> retrieveAllUsers() {
      ...
   }
}

The client side, for calling this endpoint can look like this

public class UserControl {

   @Inject
   private OctopusSCSUserRestClient restClient;

   public List<User> loadAllUsers() {
      regturn restClient.get(hostURL + "user", User[].class);
   }
}

Be aware that direct calling one SCS from another results in a tight coupling which is not suited in most situations.

The maven artifacts that one can use for this feature are be.c4j.ee.security.octopus.authentication:jwtscs-server and be.c4j.ee.security.octopus.authentication:jwtscs-client

Documentation

The user manual can be found here and example programs are created and will be available soon on GitHub.

More examples and better documentation can be expected when I migrate the Octopus framework into the Atbash organization of Github in the coming months.

Compatibility

The last section about compatibility with the current application servers. Some of the new features in this release of Octopus are only working on Java EE 7+.

Some of the new features in this release of Octopus are only working on Java EE 7+.
But in general Octopus framework can be used on any Java EE 6, Java EE 7 or Java EE 8 compliant server.

Yes, Octopus is tested with GlassFish 5 server and no issues are found. Just use the Java EE 7 version artifacts of Octopus and they will work just fine.

Later on, there will be Java EE 8 specific artifacts which use the JSONB api instead on the net.minidev:json-smart artefact.

 

Categories
Uncategorized

Hello world!

Welcome to my Atbash initiative.

All my open source coding, blog writing, and tutorials will be centralised under the name Atbash. Topics will mainly cover Java EE, Web application security and (unit and integration) Testing. But other topics like the Eclipse MicroProfile effort, Self Contained Systems, best practices or Java FX can also appear here.
All the things I use in my daily work environment and which could be interesting for you can have a place here.

I have already 2 other blogs (http://jsfcorner.blogspot.be/ and http://javaeesquad.blogspot.be/) so why a third one? Well, based on the name, the topics which should appear on those blogs is rather limited. For the Web Application security topic, for example, there was no good place to write about it.
And since I needed a domain name, see next paragraph, I created this location.

Ownership of a domain name was one of the major factors why I started with this site. Until now, my open source code was written under the name be.rubus (combination of some of the letters of my name Rudy De Busscher) or be.c4j (the company I work for and who supports open source a lot).
But since I don’t own the domain names, I was unable to deploy the code to maven central.
Transferring the code under the name be.atbash will solve this problem.

Almost all my open source work is done in my spare time. That isn’t changing. So the migration of the code will take some time. But the idea is to write some blog content in a more or less regular fashion and keep working on the open source projects like the JSF Renderer Extensions and Octopus.

Maybe the last thing; why the name atbash? According to Wikipedia, it was the first security encoding algorithm. Although too simplistic to use in our modern time, the fact that you can achieve with simple things your goal appeals to me. Java EE makes my life also simple because it lets me concentrate on the business logic, not the technical integration.

Twitter handle @Atbash_EE, Github organization atbashEE.

This website uses cookies. By continuing to use this site, you accept our use of cookies.  Learn more