Manage external accounts in Odoo:

[mourad-ehm]

After reflection with the akretion team, we propose the following

Context :

Odoo is dealing to communicate with several external services (ie 3thd party APIs).
Credentials needs to be stored securely and accessible in a clearly defined manner.
Currently each module implement this feature differently : it's a bad practice, error prone and waste of time to reimplement it.
We propose a specification of a generic module to manage accounts.

## Solution proposed :

Features:

• store account credentials
• multiple account per provider
• access restriction per society and/or per security group
• store aditionnal data (config)
• ensure data security by encrypting the identification data.

Design:

1 - store credential information in table with few columns (module_name, company_id, password, data). data will be stored in json and contain additionnal info ie {'login':'', 'key1': 'value1', 'key2': 'value2'},
2- encrypting key will be stored in config file. Potentially reduce damage if a database is leaked.
3- provide a method that allows to provides identification data (decrypting) (create a abstract object that can be inherited by business object ex stock.picking).
5 - restrict read/write by default to admin and a group "external account managers”.
6 - each consumer modules provides a dict for registration : a dict of expected info

** Example of table :**
| name | type | identifier | company_id | login | password | json data |

| Laposte | lapost | laposte_warehouse1 | 1 | 122732| ****** | {'customerId': 51221, 'agencyCode: 'paris0701'} |
| Laposte | lapost | laposte_warehouse2 | 2 | 122732| ****** | {'customerId': 53232, 'agencyCode: 'nice1323'} |
| Service aws | aws | s3_storage | 1 | 45877 | ****** | {'preferedRegion':'EU'} |

Management of multiple accounts by service provider :

In certain use case : for their shipping, the company can use the same authentification (login/password) with different customer number. For example customer number for parent company and an other customer number for subsidiary. Or customer number by white brand ext.
the sub-account use used for either statical or accounting reasons (ex: Invoice parent company and subsidiary separately)

** There 2 approaches to manage several accounts by service provider:**
1 – duplicate the account and modify only the json column (customernumber, my_other_param', ..)
2 - Split the table in to object account and account line :

• Account contain fields Name, account type, Company, login, password
  *Account line contain : account_id, key, value (json)

Use Case:

• carriers: ups, laposte, geodis
• marketplace: ebay, amazon, magento, ...
• ftp/sftp

Proposal for module name :

* credential_storage +
* keypass_manager +
* login_credential +              (translate fr: informations d'identification) 
* api_keychain

[dreispt]

Keeping keys and password in a config file has the advantage of making it simpler to refresh quality/test environments with a db copy.

[dreispt]

I suggest the implementation to expose a get values API, that can later support alternative implementations, such as using a key/value store instead of a config file.

I prefer one of the the first names: credential_storage or keypass_manager.

[hparfr]

I started an implementation here : https://github.com/akretion/ak-odoo-incubator/tree/feat/keychain8/keychain
(I will move it to our server-tools fork soon)

Since the credentials are managed by odoo, it's already possible to use conventional tools for importing data (like xml records).

[lasley]

While this module would be incredibly useful, the storing of password data with a key stored on the server is not secure. Please see our discussion in #471.

Key expiration and recoding of data encrypted by that key needs to also be a consideration. As well as the use of multiple keys in order to create an isolation of key by partner.

IMO this would also need a third party security audit before being hosted in OCA as a production module. Security is nothing to play around with, and is nearly always implemented incorrectly.

See also OWASP guidelines:

• https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

[hparfr]

Let's begin with common sense : If you want to store your data in a safe place, don't use odoo :)

I see your point, a more explicit warning message is required in the README about what kind of security you can expect of this module.

Neither this module nor Odoo should be used for storing PCI data.
This module is intended to store things like api keys or passwords to 3thd party systems you request from odoo. It's not perfect, but it's better than clear text password.
If your db (or any backup) is stolen it may buy you some days.
If your server is hacked your keys are not protected.

[dreispt]

Not minimizing the usefulness for this implementation in Odoo, but also wondering what the best solution could look like: how about having a separate, independent, service brokering this communication with 3rd party services? It could run under a different security context/user, so that it's safe if the Odoo instance is compromised. You could still get access to data if you take over Odoo, but you get access to the keys.
It could be a simple Python service, listening only to requests from trusted processes/users/whatever.

[hparfr]

It's always possible to leave the password field empty, keep the config in the module and use another layer of protection like system's certificate, a local service like you said or anything directly in the consumer.

[lasley]

Let's begin with common sense : If you want to store your data in a safe place, don't use odoo :)

This module will be available on the App Store. I can guarantee that it will be installed on production servers by administrators that did not read the disclaimer in the ReadMe.

Unfortunately common sense escapes many, particularly those who have come to trust the OCA brand as something they don't need to review (outside of PR).

This is a problem that I have been fighting against in Vertical Medical, and have had to simply deprecate attributes during upgrade because they are not safe. OCA is here to protect the users from themselves, and app installations are user level.

also wondering what the best solution could look like

@dreispt - What you are talking about, I am trying to figure out myself as well. I think @hbrunn's method of PGP via JS is the most secure solution personally.

I am planning on making some concessions in some areas for data that is required by the system, but I am not quite done with that idea yet.

I do also like the idea of a separate service. I created a Golang app recently to do some key management & other useful things, and have been thinking of integrating it into Clouder

[lasley]

Closing, PR #644 was created and merged - which I believe covers the features of this req