diff options
| -rw-r--r-- | TODO | 14 | ||||
| -rw-r--r-- | notes/auth_thoughts.txt | 37 |
2 files changed, 49 insertions, 2 deletions
@@ -1,10 +1,20 @@ ## In Progress +- authentication! + => unit tests + => refactor to use other macaroons lib + => env key passing + => RBAC infra + => wire up fatcatd (env, cli) + => check permissions everywhere + => toml or similar key-right +- webface auth + ## Next Up -- fileset/webcapture entities -- authentication +- cargo update (rust deps) +- pipenv update (python deps) - remove the concept of "active editgroup", and simplify autoaccept batch path - fix returned error messages; should return type (shortname), and then actual message/description diff --git a/notes/auth_thoughts.txt b/notes/auth_thoughts.txt index ba19f4c2..c82b204e 100644 --- a/notes/auth_thoughts.txt +++ b/notes/auth_thoughts.txt @@ -59,3 +59,40 @@ support oauth2 against: - github ? google +Macaroon details: +- worth looking at "bakery" projects (python and golang) for example of how to + actually implement macaroon authentication/authorization +- location is fatcat.wiki (and/or qa.fatcat.wiki, or test or localhost or test.fatcat.wiki?) +- identifier is a UUID in upper-case string format +- will need some on-disk key storage thing? + => how to generate new keys? which one should be used, most recent? + conception of revoking keys? simple JSON/TOML, or LMDB? +- call them "authentication tokens"? +- params/constraints + - editor_id: always, fcid format + - created: always, some date format (seconds/iso) + - expires: optional, same date format + +It's a huge simplification to have webface generate macaroons as well, using a +root key. webface doesn't need multiple keys because it only creates, doesn't +verify. + +Code structure: +- auth service/struct is generated at startup; reads environment and on-disk keys +- verify helper does the thing +- some sort of auth/edit context + +Roles? +- public: unauthenticated +- editor: any authenticated, active account +- bot +- admin + +Caveats: +- general model is that macaroon is omnipotent and passes all verification, + unless caveats are added. eg, adding verification checks doesn't constrain + auth, only the caveats constrain auth; verification check *allow* additional + auth. each caveat only needs to be allowed by one verifiation. +- can (and should?) add as many caveat checkers/constrants in code as possible + +http://evancordell.com/2015/09/27/macaroons-101-contextual-confinement.html |