hypertopic / aaaforrest Goto Github PK

Three years ago, we discussed here how to configure CouchDB and AAAforREST to interact together. I have been using these settings with CouchDB 1.6 up to now. Today, it is time to move to CouchDB 2.3.

Hereunder are a few questions on how to set up such a system.

The way we configured CouchDB 1.6 is not suitable for CouchDB 2.3, namely because configuration may not be performed with such command lines.

Let's start with the following settings :

As CouchDB 1.6, CouchDB 2.3 includes a section entitled couch_httpd_auth. I thus suppose nothing changed concerning the first two settings. Does this assumption sounds correct to you ?

CouchDB 2.3 configuration includes two different sections chttpd and httpd. Given default configuration associates chttpd to port 5984 and httpd to port 5986, I guess that authentication_handlers settings should be included under chttpd. However, in the default configuration, chttpd does not contain any option authentication_handlers. Should I create such an option, or should I include this setting in another section ?

In real settings (inside a browser), DELETE /_session will send a preflight OPTIONS which is not handled by AAAforREST for now.

It has been reported that passwords with special characters (maybe +, %, or &) failed when used with LaSuli and AAAforREST. It is still not clear on which side is the problem (see duplicate ticket).

Applications such as L4L or TraduXio can provide a list of who can do what on what.

Raised on GET /_session when site cookies are set up and noone is logged yet.

The log says:

TypeError: Cannot read property 'login' of undefined. RULE xxx.acme.com #0

@christophe-lejeune

Je me rends compte que le nouvel exemple de fichier de configuration est extrêmement long par rapport à celui que j'utilisais jusque là (qui ne dépassait pas les 20 lignes).

Don't be afraid by the length of config.sample.json. It aims at providing every possible settings to be tested by automatic tests.
Between an older and a newer version of AAAforREST, for the same features, the number of lines should be nearly the same (it could even be shorter thanks to default values!).

Existe-t-il une page documentant comment adapter ce fichier ?

Every option is mentioned and explained there:
https://github.com/Hypertopic/AAAforREST/blob/master/conf/config.sample.js

Please note that most options have now default values:
so, if you read //host: "localhost", and that your host is indeed localhost, you don't need to write anything.

Les différents "ports" (A, B) utilisés doivent-ils rester tels quels ou peuvent-ils être modifiés ? Dans ma configuration actuelle, ils sont différents de cet exemple.

Of course you can change them. Here again, config.sample.json is just here to make tests pass and "document" every single feature. Depending on your needs, you can have very very different config.json or config.js (be careful rules syntax is slightly different when defined as strings or as functions).

Il me semble que, dans sa structure, ce fichier comporte plusieurs d'exemples ("sites"). Faut-il tous les conserver pour que les choses fonctionnent ? (...) Ou, au contraire, puis-je supprimer tous ces exemples ("sites") et en revenir à un fichier assez court (avec une seule section, dédiée au CouchDB de Cassandre) ?

If you just have one site, just keep one site in the settings.

Les sections relatives "auth_fixed.local" ou "preserveCredentials" gèrent-elles des aspects vitaux des interactions entre AAAforREST et couchDB... D'autant que "forwardedLoginSecret" n'apparaît que dans un de ces exemples. (...) Enfin, dans ta dernière réponse, tu dis qu'une seule ligne permet de tout gérer ? De quelle ligne s'agit-il ? Celle qui définit une règle (rule) ?

I think it is not too badly explained in the file I mentioned (config.sample.js).
If it is not clear please ask again.

If I understand righty, you must not preserve credentials (preserveCredentials) since your CouchDB won't do anything good with LDAP passwords, but you have to forward login (forwardedLoginSecret) when LDAP says credentials are OK.

Je suppose également qu'il serait sans doute plus sécure de supprimer tous les mots de passe saisis en dur dans ce fichier exemple...

Definitely! If I use static credentials in tests it is just because they are simpler to configure and faster to test.

Please feel free to propose a draft of settings here for Cassandre (without secrets and with anonymized servers of course). I (and maybe @franck-eyraud) will try to tune it with you.

... "à la GitHub".

The user himself/herself would be chosen in a tag cloud.

The general idea is to send an e-mail with a URI that cannot be forged.

A. Different options could be used in the URI to make it unforgeable:

1. a document UUID (if there are no other way to create one or to list them),
2. a hash of the login (or e-mail) salted with a secret,
3. a true asymetric digital signature,
4. a one-time token (e.g. UUID) added to the user document by an admin.

B. On CouchDB's side, the password can be reset either:

1. by the user itself (which would be applicable for password reset only with proxyauth set up on CouchDB and if the proxy can check the unforgeable URI itself),
2. by an administrator (which means that the service that checks the unforgeable URI should know the admin credential),
3. by anonymous in admin party (not applicable).

For implementation simplicity (balanced with security), I would favor solution A.4+B.2.
@franck-eyraud Do you think about other solutions or do you favor another one?

Thank you very much for the great work done on AAAforREST !

I would like to use it with my university's LDAP. My first attempt was successful. That'a already great !

However, I realized that my LDAP have "subdomains" for different types of students. In the example provided in conf/config.yml, we would have two different search bases, one with dc=example,dc=com and the other with dc=master,dc=example,dc=com. Each configuration works if it is used alone. But I fail to use it altogether.

As you can see, the search bases have dc=example,dc=com in common. Unfortunately, queries on dc=example,dc=com gives no answer concerning dc=master,dc=example,dc=com. Do you think it would be possible to generate "recursive" queries to this LDAP ? Or should we consider these two search bases as two different LDAP, as in first version of AAAforREST ?

I would be happy to conduct tests under your direction.

Again many thanks and best wishes !

AAAforREST config file allows to define general "rules" for authentication.

On the top of these rules, thanks to the "restricted" parameter, the access to dedicated resources can be restricted to specific users.

When general rules are already quite complex, it would be convenient that a comparable parameter permits to define the opposite behaviour : not restricting but opening dedicated resource's access to anyone (including guest users, with no password). This parameter would be helpful to set sandboxes, demos or public examples, for instance.

Revision 6579a57 implemented an emulation of CouchDB's cookie authentication.

In this ticket, I will try to document the settings needed to acticate this feature and use it with Agorae (the only Hypertopic piece of software using cookies).

First I edited conf/config.json to add a sessionHandler section to the original settings:

{
  "port": 1337,
  "sessionHandler": {
    "cookieName": "AAAforRest-auth",
    "sessionLength": 600000,
    "userfield": "name",
    "passfield": "password",
    "path": "/_session",
    "preserveCredentials": false,
    "forward": false
  },
  "sites": [{
    "hostProxy": "agorae.local",
    "port": 5984,
    "path": "/agorae/_design/transutt/_rewrite",
    "preserveCredentials": false,
    "hideLocationParts": 1,
    "rules":[]
}]}

... are not properly parsed.

This is due to the way HTTP basic authentication is parsed:
token.split(':')[1] is not necessarily the whole password.

TraduXio needs to find all the users login matching the display name sent in the request.

On the production server when both LDAP and HTTP authenticators are defined on the site,
the second time a request is done to get a resource representation, the request never ends...

I didn't achieve to reproduce it on test settings yet.

Reported by @christophe-lejeune :

Cannot read property 'dn' of undefined is raised when cookies (aka SSO) is not defined in the configuration file.

Workaround

Copy your site related authentication section in the main section.

Alexis created a nice user registration form.

Users are created on CouchDB and can be used for authentication on AAAforREST (with HTTP basic or cookie on frontend, and HTTP basic on backend) or even through AAAforREST with cookie forwarding.

In the future, it could be upgraded with e-mail verification, password reset, etc.

As an HTML+jQuery page it can be served either by CouchDB as attachments (as it is for now) or by NodeJS.

However the real point is how this UI and the corresponding API (_users) will be integrated with existing apps:

• as a javascript altering the app UI,
• as an other web app (e.g. http://auth.acme.org/),
• as a special handler available to any app that wants it (e.g. http://app.acme.org/_users) – the registration app would be stored in the users database,
• as the body of the 404 error (choose "cancel" )

Of course we could adopt two solutions at the same time (solution 4 and one of the first three) to let the integrator choose between modifying the apps or not.

An objection against solution 2 could be raised if we wanted to automatically authenticate after registration (unless a cookie can be set for every subdomain of the same domain). However, I wonder if it is a good thing as many password manager don't record credentials in such cases.

@franck-eyraud Do you think about any other way to integrate it, any other criterion we should consider, or any comment on mine?

Such as:

• institutional and community LDAP directories (e.g. for Cassandre & Argos),
• institutional LDAP directory and CouchDB users (e.g. for L4L).

Hereunder are a few questions concerning interactions between AAAforRest and Cassandre.

• AAAforREST includes mentions of Single sign-on (SSO). Does it mean that AAAforRest is compliant with academic repositories managed through SSO ? If not, is it intended to become ?
• Am I right to assume that access to resources is granted on the basis of their URI ? If so, this would answer one of Cassandre's issue related to URI's.
• How is the server supposed to interact with AAAforRest ? For instance, when a diary is created under Cassandre, the user may invite registered users. Is the server (Cassandre) supposed to add one rule in AAAforREST configuration file ? Or is it supposed to work differently ?

In the future simplified rules system, what would be the syntax for the following rules?

"rules": [{
  "control": "/(56e092d8a6179a788c74b618b29801c0|a76306e4f17ed4f79e7e481eb9a1bd06)/.test(path) && method != 'GET' && !/^(aurelien|jean_pierre)$/.test(login)",
  "action": "tryAgain(context)"
},{
  "control": "method != 'GET' && method != 'OPTIONS'",
  "action": "authenticate(context, function(){proxyWork(context);});"
}]

e.g. for a group or a set of groups.

    getSession,
    aaa.loadInSession,

could be replaced with:

     aaa.restoreSession

Other functions related to sessions could also benefit from this kind of simplification.

Handling CORS on AAAforREST would prevent to implement it on the upstream server (as here).

In a first implementation, the origins white-list defined in the settings could be sent as such (exactly as in the previous link).

It seems that 1c4384c broke the authentication in Steatite.