+9
Under review

Unprivileged API tokens

Mike Wilson 7 years ago updated by finalbeta 5 years ago 4

Create API keys that don't have access to passwords directly, but do have access to custom fields like password hash, public keys, etc.  This way Puppet/Ansible can query TeamPass directly to set passwords without any sort of intermediary step.

Under review

Thank you.


Can you please give more details because I don't get the interest of this?

Thanks for the reply, and thanks for all the tireless and hard work! :)


I'd like to have specific API keys that can't see raw passwords.  This way automation can retrieve account metadata without exposing credentials.  Specifically, I want to store password hash (as description right now) and have puppet clients pull it directly from Teampass for rollout without having to widely distribute an API key that has access to the entire store.


I would still want API keys that function like today as well so I can have automation interact with the password store (distributing changed passwords, etc).


Does that help at all?

+1

I think what would help here, is if individual API tokens could be associated with a Role to restrict their access, rather than all API tokens just having the same global read/write over everything.


That way, puppet could use an API token with read-only privileges to just one part of the tree; other applications could have read/write to different sections.


Mike seems to be asking for the API privileges to be further restricted to certain fields in the item.  This would be good if we could define roles to have permissions at a field level rather than folder or item level, but it might be a bit hard to achieve, particularly with userdefined fields


+1 for the idea of different roles for different API tokens

+1

+1 for individual user tokens. 
An API usually has different uses. 

  • Administrative access: Create folders based on an external system, access items from an external system.
  • User access: Application for user X access credentials user X has access to. Use Y runs the same application using his own credentials, he should only have rights to his own credentials.