Support for non-authenticated users

[psrok1]

Describe the problem

Based on partially implemented draft #319. PR https://github.com/CERT-Polska/mwdb-core/pull/334 implemented registered group (renamed variant of previous trusted proposal)

Users are by default added to registered group that contains default capabilities for typical MWDB users. This group is optional, so if you want to create less-privileged account, you can put user out of this group.

Use cases:

• Sharing chosen objects publicly and without authentication requirement.
• Sharing part of dataset.

This draft contains proposal of non-authenticated users representation.

Describe the solution you'd like

Let's introduce nobody user that represents unauthenticated user identity. nobody group describes what unauthenticated user can. nobody user is a virtual identity that is required to keep everything consistent. nobody is not a member of any other group, including public group (the only exception from current model). All capabilities are given exclusively for nobody.

To authorize as nobody user: everyone can generate a unique authorization token that identifies a user. User identity is based on fingerprint (IP address). nobody's authorization token has expiration time like other password-authenticated sessions and can be renewed at any time before expiration. Rate-limiting or other things related with specific user identity (e.g. bans) are based on the fingerprint.

Unauthenticated access is turned off by default, It's completely optional and the specific flag in mwdb.ini is required to turn it on.

Currently if object is shared, access is inherited by its children, so we share the whole subtree of objects. That may not be an intended behavior when we share something publicly. That's why we need to make another exception for sharing with nobody.

Note: MWDB code contains some optimizations that assume that user always has access to all of its children (full listing of object's children without checking ACLs).

In addition: nobody implementation requires even more granular capabilities. We may want to introduce:

• list_objects to ban unauthenticated users from listing/searching for public resources (access requires link/known hash)
• access_stats to ban users from accessing statistics (if someone doesn't want to share family list)