Backend security

[jri]

Each HTTP request must pass a filter chain for authorization. The authorization check must involve the instance's ACLs entries (#262) and the user's authentication status. The user session must be represented by a server-side HTTP session whose ID is stored in a browser cookie. If request authorization fails 401 or 403 must be returned.

Thanks, dgf, for pushing this topic now!
and for the Spring Security hint.

[jri]

There is a variety of security frameworks for that purpose. Popular ones include

• Spring Security

(​http://www.springsource.org/spring-security/)

• Apache Shiro

(​http://shiro.apache.org/)

Here is my first impression:

Spring Security is complicated. Perhaps too complicated. At least not very accessible for a first-time (non-Spring) user.

Apache Shiro on the other hand feels very friendly. Easy to understand concepts and clear wording. Very good documentation, also for beginners. For the time being Apache Shiro is clearly my favorite.

But what could render headaches is, again, the OSGi environment. In particular the limits of its HTTP service. The OSGi HTTP service specification neither supports (Servlet API) Filters nor Servlet Context Listeners. While Felix HTTP provides a non-standard extension for Filters (same for Equinox) there is no support for Listeners.

Since version 1.2 Apache Shiro relies on Servlet Context Listeners as the central Shiro SecurityManager? object is created in a Listener. The previous version, Shiro 1.1, in contrast creates the SecurityManager? in a Filter which might work well with Felix.

Things we could consider:

• Start with Shiro 1.1. Possibly it provides all the features we need for the moment.
• Investigate how to deploy Shiro 1.2 for OSGi web applications (I saw some not-so-nice approaches already).
• Ask the Shiro developers for supporting the OSGi web application scenario.

[jri]

The missing Servlet Context Listeners seems not to be a problem at all. Despite some disadvantages the Shiro SecurityManager? object can be constructed programatically. See ​http://shiro.apache.org/configuration.html

[dgf]

Another possibility can be the JSR 250 support of jersey

an short introduction: ​Jersey JAX-RS, Tomcat, Basic Auth and Security Annotations

a programmatically filter configuration is also supported

class WebPublishingService
....
String[] filters = new String[]{RolesAllowedResourceFilterFactory.class.getName()};
rootApplication.getProperties().put(ResourceFilters.class.getName(), filters);
jerseyServlet = new ServletContainer(rootApplication);

[jri]

Thanks, dgf, for that hint!
The Jersey filters open a set of new possibilities.
Perhaps we can start even without using a security framework.

My next goal is securing the application as whole:
1) Starting the Webclient must require to login. That is, the very first request must result in 401 if not logged in.
This requires securing the static resources (scripts). As these are not delivered by Jersey (but Jetty directly) I will try to setup a Filter (Servlet API, not Jersey API) via Felix's ExtHttpService?.
2) For securing the REST resources I will try Jersey Container Filters. All REST resources must accessible only for logged in users.

Finer granularity (ACL-based at instance-level) could be realized later on by the Jersey Resource Filters you mentioned.

Thanks, dgf, for the phone discussion!

[Jörg Richter]

Core: try out Jersey Container Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: b4a18319f54277b6e9c990035abe531ac58fd5a0
• URL: ​https://github.com/jri/deepamehta/commit/b4a18319f54277b6e9c990035abe531ac58fd5a0

[Jörg Richter]

Core: try out Servlet Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: ddd4c3062498f8fbfa7ec049757257834600bc09
• URL: ​https://github.com/jri/deepamehta/commit/ddd4c3062498f8fbfa7ec049757257834600bc09

[Jörg Richter]

Core: new setting dm4.installation.type (#293).

There are 4 DeepaMehta installation types (left column):

                    Net Interface       Read                Write
------------------------------------------------------------------------
SINGLE-USER         localhost           yes                 yes
(default)

PRIVATE             all                 if logged in        if logged in

PUBLIC              all                 yes                 if logged in

SANDBOX             all                 yes                 yes

See ticket 293.

• Changeset: bd4452c516363d3e85b6fc50ccc976bc0d200257
• URL: ​https://github.com/jri/deepamehta/commit/bd4452c516363d3e85b6fc50ccc976bc0d200257

[Jörg Richter]

Extend Access Control service by login() (#293).

See ticket 293.

• Changeset: 486c62ce74b8f1c59544f7559c3f3d4b836fb18d
• URL: ​https://github.com/jri/deepamehta/commit/486c62ce74b8f1c59544f7559c3f3d4b836fb18d

[Jörg Richter]

Access Control: fix cyclic dependency (#293).

The request filter is setup by the Access Control plugin (instead by DM4 Core).

Changed in Access Control service:

• login() renamed to checkCredentials()
• getUsername() has no parameter anymore ("clientState" is dropped)
• getTopicPermissions() has no "clientState" parameter anymore

Furthermore in DM4 Core: a plugin can register a (Servlet API) filter by calling

• registerFilter(Filter filter) declared in plugin base class

See ticket 293.

• Changeset: 520c95c0492c34c5647fc329d880f7231e28975e
• URL: ​https://github.com/jri/deepamehta/commit/520c95c0492c34c5647fc329d880f7231e28975e

[Jörg Richter]

Access Control: create HTTP sessions (#293).

For a logged in user a HTTP session is created.
The dm4_username cookie is not used anymore.

Furthermore in Webclient: the API method require_login() is removed.

See ticket 293.

• Changeset: faa7485e02f3caeb506853d1a67db0b5f941f9f1
• URL: ​https://github.com/jri/deepamehta/commit/faa7485e02f3caeb506853d1a67db0b5f941f9f1

[Jörg Richter]

Access Control: logout (#293).

Once logged out the HTTP session is invalidated.

Changes in Access Control service:

• logout() is added
• lookupUserAccount() is dropped

See ticket 293.

• Changeset: 46eb819cd890d83dd1f51602d0be53ec5e293737
• URL: ​https://github.com/jri/deepamehta/commit/46eb819cd890d83dd1f51602d0be53ec5e293737

[Jörg Richter]

Access Control: drop "installation type" (#293).

Instead the "dm4.installation.type" config property there are 2 separate boolean properties in global pom.xml:

• dm4.security.read_requires_login # default is "false"
• dm4.security.write_requires_login # default is "true"

See ticket 293.

• Changeset: a0b48d3ae98c89a29a5dedd22dacb11154435524
• URL: ​https://github.com/jri/deepamehta/commit/a0b48d3ae98c89a29a5dedd22dacb11154435524

[Jörg Richter]

Access Control: logout shuts down client (#293).

When logging out from a "private" DM installation the webclient shuts down, that is the browser window is emptied. This reflects the meaning of a "private" installation: the webclient is only accessible when logged in.

A DM installation is made "private" by setting the config property dm4.security.read_requires_login to true (in global pom.xml):

    <dm4.security.read_requires_login>true</dm4.security.read_requires_login>

Note this drawback: the next request logs in the user automatically. This is a known problem with HTTP Basic authentication.

See ticket 293.

• Changeset: a661efb0682de5a6b3892fd4aa7a278c4a4f0445
• URL: ​https://github.com/jri/deepamehta/commit/a661efb0682de5a6b3892fd4aa7a278c4a4f0445

[Jörg Richter]

Access Control: global subnet filter (#293).

The subnet filter of the Files plugin is moved to the Access Control plugin.
The subnet check is applied to *every* request (not just file requests).

There is a new config property in global pom.xml:

    <dm4.security.subnet_filter>127.0.0.1/32</dm4.security.subnet_filter>

The former dm4.filerepo.netfilter property is dropped.

See ticket 293.

• Changeset: aef56ac8f3d894bb3d10c99a7540ad38814c7ad4
• URL: ​https://github.com/jri/deepamehta/commit/aef56ac8f3d894bb3d10c99a7540ad38814c7ad4

[Jörg Richter]

Core: try out Jersey Container Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: b4a18319f54277b6e9c990035abe531ac58fd5a0
• URL: ​https://github.com/jri/deepamehta/commit/b4a18319f54277b6e9c990035abe531ac58fd5a0

[Jörg Richter]

Core: try out Servlet Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: ddd4c3062498f8fbfa7ec049757257834600bc09
• URL: ​https://github.com/jri/deepamehta/commit/ddd4c3062498f8fbfa7ec049757257834600bc09

[Jörg Richter]

Core: new setting dm4.installation.type (#293).

There are 4 DeepaMehta installation types (left column):

                    Net Interface       Read                Write
------------------------------------------------------------------------
SINGLE-USER         localhost           yes                 yes
(default)

PRIVATE             all                 if logged in        if logged in

PUBLIC              all                 yes                 if logged in

SANDBOX             all                 yes                 yes

See ticket 293.

• Changeset: bd4452c516363d3e85b6fc50ccc976bc0d200257
• URL: ​https://github.com/jri/deepamehta/commit/bd4452c516363d3e85b6fc50ccc976bc0d200257

[Jörg Richter]

Extend Access Control service by login() (#293).

See ticket 293.

• Changeset: 486c62ce74b8f1c59544f7559c3f3d4b836fb18d
• URL: ​https://github.com/jri/deepamehta/commit/486c62ce74b8f1c59544f7559c3f3d4b836fb18d

[Jörg Richter]

Access Control: fix cyclic dependency (#293).

The request filter is setup by the Access Control plugin (instead by DM4 Core).

Changed in Access Control service:

• login() renamed to checkCredentials()
• getUsername() has no parameter anymore ("clientState" is dropped)
• getTopicPermissions() has no "clientState" parameter anymore

Furthermore in DM4 Core: a plugin can register a (Servlet API) filter by calling

• registerFilter(Filter filter) declared in plugin base class

See ticket 293.

• Changeset: 520c95c0492c34c5647fc329d880f7231e28975e
• URL: ​https://github.com/jri/deepamehta/commit/520c95c0492c34c5647fc329d880f7231e28975e

[Jörg Richter]

Access Control: create HTTP sessions (#293).

For a logged in user a HTTP session is created.
The dm4_username cookie is not used anymore.

Furthermore in Webclient: the API method require_login() is removed.

See ticket 293.

• Changeset: faa7485e02f3caeb506853d1a67db0b5f941f9f1
• URL: ​https://github.com/jri/deepamehta/commit/faa7485e02f3caeb506853d1a67db0b5f941f9f1

[Jörg Richter]

Access Control: logout (#293).

Once logged out the HTTP session is invalidated.

Changes in Access Control service:

• logout() is added
• lookupUserAccount() is dropped

See ticket 293.

• Changeset: 46eb819cd890d83dd1f51602d0be53ec5e293737
• URL: ​https://github.com/jri/deepamehta/commit/46eb819cd890d83dd1f51602d0be53ec5e293737

[Jörg Richter]

Access Control: drop "installation type" (#293).

Instead the "dm4.installation.type" config property there are 2 separate boolean properties in global pom.xml:

• dm4.security.read_requires_login # default is "false"
• dm4.security.write_requires_login # default is "true"

See ticket 293.

• Changeset: a0b48d3ae98c89a29a5dedd22dacb11154435524
• URL: ​https://github.com/jri/deepamehta/commit/a0b48d3ae98c89a29a5dedd22dacb11154435524

[Jörg Richter]

Access Control: logout shuts down client (#293).

When logging out from a "private" DM installation the webclient shuts down, that is the browser window is emptied. This reflects the meaning of a "private" installation: the webclient is only accessible when logged in.

A DM installation is made "private" by setting the config property dm4.security.read_requires_login to true (in global pom.xml):

    <dm4.security.read_requires_login>true</dm4.security.read_requires_login>

Note this drawback: the next request logs in the user automatically. This is a known problem with HTTP Basic authentication.

See ticket 293.

• Changeset: a661efb0682de5a6b3892fd4aa7a278c4a4f0445
• URL: ​https://github.com/jri/deepamehta/commit/a661efb0682de5a6b3892fd4aa7a278c4a4f0445

[Jörg Richter]

Access Control: global subnet filter (#293).

The subnet filter of the Files plugin is moved to the Access Control plugin.
The subnet check is applied to *every* request (not just file requests).

There is a new config property in global pom.xml:

    <dm4.security.subnet_filter>127.0.0.1/32</dm4.security.subnet_filter>

The former dm4.filerepo.netfilter property is dropped.

See ticket 293.

• Changeset: aef56ac8f3d894bb3d10c99a7540ad38814c7ad4
• URL: ​https://github.com/jri/deepamehta/commit/aef56ac8f3d894bb3d10c99a7540ad38814c7ad4

[jri]

Summary:
The backend (its REST API) is secured at a coarse level: each request must pass a filter. The filter is controlled by 3 config properties:

dm4.security.read_requires_login       # default: false
dm4.security.write_requires_login      # default: true
dm4.security.subnet_filter             # default: 127.0.0.1/32

This is sufficient e.g. to deploy a shared private DM installation -> set both flags to ”true" and the netfilter to "0.0.0.0/0".
No (per-instance) ACLs are involved at this level.
For the moment this is considered sufficient and the ticket is now closed.

[Jörg Richter]

Access Control: login is a POST request (#293).

Login via REST API now uses Basic Authentication.

To login:

    POST /accesscontrol/login

Put username and passwort in the "Authorization" header, according to Basic Authentication:
The string "Basic " appended by the Base64 encoded form of "{username}:{password}".

Note: no RequestFilter? rule exception is required. The POST request is autorized on-the-fly via Basic Authentication.
(Basic Authentication allows to send the "Authorization" header along with the initial request, not forcing a 401).

Further changes in Webclient:
The RESTClient's public request() method takes a "headers" object (replacing the "content_type" parameter).
A plugin can pass arbitrary request headers.

    this.request = function(method, uri, data, headers)

See ticket 293.

• Changeset: 6870789a4a1353d214dd2307d53d22170e72f2c4
• URL: ​https://github.com/jri/deepamehta/commit/6870789a4a1353d214dd2307d53d22170e72f2c4

[Jörg Richter]

Access Control: login is a POST request (#293).

Login via REST API now uses Basic Authentication.

To login:

    POST /accesscontrol/login

Put username and passwort in the "Authorization" header, according to Basic Authentication:
The string "Basic " appended by the Base64 encoded form of "{username}:{password}".

Note: no RequestFilter? rule exception is required. The POST request is autorized on-the-fly via Basic Authentication.
(Basic Authentication allows to send the "Authorization" header along with the initial request, not forcing a 401).

Further changes in Webclient:
The RESTClient's public request() method takes a "headers" object (replacing the "content_type" parameter).
A plugin can pass arbitrary request headers.

    this.request = function(method, uri, data, headers)

See ticket 293.

• Changeset: 6870789a4a1353d214dd2307d53d22170e72f2c4
• URL: ​https://github.com/jri/deepamehta/commit/6870789a4a1353d214dd2307d53d22170e72f2c4

[Jörg Richter]

Core: try out Jersey Container Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: b4a18319f54277b6e9c990035abe531ac58fd5a0
• URL: ​https://github.com/jri/deepamehta/commit/b4a18319f54277b6e9c990035abe531ac58fd5a0

[Jörg Richter]

Core: try out Servlet Filters (#293).

Just an experiment. Nothing useful for the moment.

See ticket 293.

• Changeset: ddd4c3062498f8fbfa7ec049757257834600bc09
• URL: ​https://github.com/jri/deepamehta/commit/ddd4c3062498f8fbfa7ec049757257834600bc09

[Jörg Richter]

Core: new setting dm4.installation.type (#293).

There are 4 DeepaMehta installation types (left column):

                    Net Interface       Read                Write
------------------------------------------------------------------------
SINGLE-USER         localhost           yes                 yes
(default)

PRIVATE             all                 if logged in        if logged in

PUBLIC              all                 yes                 if logged in

SANDBOX             all                 yes                 yes

See ticket 293.

• Changeset: bd4452c516363d3e85b6fc50ccc976bc0d200257
• URL: ​https://github.com/jri/deepamehta/commit/bd4452c516363d3e85b6fc50ccc976bc0d200257

[Jörg Richter]

Extend Access Control service by login() (#293).

See ticket 293.

• Changeset: 486c62ce74b8f1c59544f7559c3f3d4b836fb18d
• URL: ​https://github.com/jri/deepamehta/commit/486c62ce74b8f1c59544f7559c3f3d4b836fb18d

[Jörg Richter]

Access Control: fix cyclic dependency (#293).

The request filter is setup by the Access Control plugin (instead by DM4 Core).

Changed in Access Control service:

• login() renamed to checkCredentials()
• getUsername() has no parameter anymore ("clientState" is dropped)
• getTopicPermissions() has no "clientState" parameter anymore

Furthermore in DM4 Core: a plugin can register a (Servlet API) filter by calling

• registerFilter(Filter filter) declared in plugin base class

See ticket 293.

• Changeset: 520c95c0492c34c5647fc329d880f7231e28975e
• URL: ​https://github.com/jri/deepamehta/commit/520c95c0492c34c5647fc329d880f7231e28975e

[Jörg Richter]

Access Control: create HTTP sessions (#293).

For a logged in user a HTTP session is created.
The dm4_username cookie is not used anymore.

Furthermore in Webclient: the API method require_login() is removed.

See ticket 293.

• Changeset: faa7485e02f3caeb506853d1a67db0b5f941f9f1
• URL: ​https://github.com/jri/deepamehta/commit/faa7485e02f3caeb506853d1a67db0b5f941f9f1

[Jörg Richter]

Access Control: logout (#293).

Once logged out the HTTP session is invalidated.

Changes in Access Control service:

• logout() is added
• lookupUserAccount() is dropped

See ticket 293.

• Changeset: 46eb819cd890d83dd1f51602d0be53ec5e293737
• URL: ​https://github.com/jri/deepamehta/commit/46eb819cd890d83dd1f51602d0be53ec5e293737

[Jörg Richter]

Access Control: drop "installation type" (#293).

Instead the "dm4.installation.type" config property there are 2 separate boolean properties in global pom.xml:

• dm4.security.read_requires_login # default is "false"
• dm4.security.write_requires_login # default is "true"

See ticket 293.

• Changeset: a0b48d3ae98c89a29a5dedd22dacb11154435524
• URL: ​https://github.com/jri/deepamehta/commit/a0b48d3ae98c89a29a5dedd22dacb11154435524

[Jörg Richter]

Access Control: logout shuts down client (#293).

When logging out from a "private" DM installation the webclient shuts down, that is the browser window is emptied. This reflects the meaning of a "private" installation: the webclient is only accessible when logged in.

A DM installation is made "private" by setting the config property dm4.security.read_requires_login to true (in global pom.xml):

    <dm4.security.read_requires_login>true</dm4.security.read_requires_login>

Note this drawback: the next request logs in the user automatically. This is a known problem with HTTP Basic authentication.

See ticket 293.

• Changeset: a661efb0682de5a6b3892fd4aa7a278c4a4f0445
• URL: ​https://github.com/jri/deepamehta/commit/a661efb0682de5a6b3892fd4aa7a278c4a4f0445

[Jörg Richter]

Access Control: global subnet filter (#293).

The subnet filter of the Files plugin is moved to the Access Control plugin.
The subnet check is applied to *every* request (not just file requests).

There is a new config property in global pom.xml:

    <dm4.security.subnet_filter>127.0.0.1/32</dm4.security.subnet_filter>

The former dm4.filerepo.netfilter property is dropped.

See ticket 293.

• Changeset: aef56ac8f3d894bb3d10c99a7540ad38814c7ad4
• URL: ​https://github.com/jri/deepamehta/commit/aef56ac8f3d894bb3d10c99a7540ad38814c7ad4

[Jörg Richter]

Access Control: login is a POST request (#293).

Login via REST API now uses Basic Authentication.

To login:

    POST /accesscontrol/login

Put username and passwort in the "Authorization" header, according to Basic Authentication:
The string "Basic " appended by the Base64 encoded form of "{username}:{password}".

Note: no RequestFilter? rule exception is required. The POST request is autorized on-the-fly via Basic Authentication.
(Basic Authentication allows to send the "Authorization" header along with the initial request, not forcing a 401).

Further changes in Webclient:
The RESTClient's public request() method takes a "headers" object (replacing the "content_type" parameter).
A plugin can pass arbitrary request headers.

    this.request = function(method, uri, data, headers)

See ticket 293.

• Changeset: 6870789a4a1353d214dd2307d53d22170e72f2c4
• URL: ​https://github.com/jri/deepamehta/commit/6870789a4a1353d214dd2307d53d22170e72f2c4