Security System Proposal

Introduction

When accessing externals resources we may need to provide some kind of authentication. The needed authentication will depend on the type of resource we are accessing, some resources may require a simple basic authentication others may require a more specific one like GeoServer authkey.

We should be able to configure in a centralized way which authentication mechanism should be used based on a request URL.

Authentication Rules

Authentication rules will allow us to configure which authentication mechanism should be used when requesting a certain URL. Authentication rules will be provided as a configuration property and will look like this:

{
  "authenticationRules": [
    {
      "urlPattern": ".*89.114.15.450.*?geoserver.*",
      "method": "authkey"
    },
    {
      "urlPattern": "*?geoserver.*",
      "method": "basic"
    }
  ]
}

The authentication rules will be applied in the order they were declared. In the example above we are configuring that basic authentication should be used to access GeoServer instances except for a specific instance where authkey mechanism should be used instead.

The SecurityUtils.js class should provided the helper methods need to deal with the authentication rules. Who invokes this helpers methods will be responsible to provide the current authenticated user details. Given a request URL we should be able to get back the needed authentication method. Given a request URL and an axios configuration object we should be able to get back the axios configuration object setup with the proper authentication mechanism.

Setting Authentication

When accessing a resource we can set the authentication explicitly or implicitly.

Explicitly

Setting the authentication explicitly will require that every component that needs to access an external resource will need to receive as a prop the current authentication information and set the correct authentication using the SecurityUtils.js helpers (SecurityUtils.js will help reduce code duplication).

Pros

• Fits well in the current architecture, the authentication info will be provided as a prop to a "dumb" component.

Cons

• Every component that needs to access an external resource will need to explicitly set the correct authentication.

Implicitly

Another options is setting the authentication implicitly where possible. We can use axios interceptors to setup the correct authentication automatically without the component be aware of it. Although, this will bring some technical challenges.

The axios interceptor will not have access to the current state of the application so we will need to get the authentication information from another place. We can store the authentication information in a cookie or in the local storage or we can invoke some hooks in SecurityUtils.js for login and logout and store the authentication information in the SecurityUtils.js object.

Not everything uses axios to access external resources and those use cases will need to be handled explicitly.

Pros

• Some components will not need to worry about authentication concerns.

Cons

• Will not work for all use cases.
• The authentication information will not be accessed from the application state.