summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--TODO14
-rw-r--r--notes/auth_thoughts.txt37
2 files changed, 49 insertions, 2 deletions
diff --git a/TODO b/TODO
index 7692444b..9a69ab7d 100644
--- a/TODO
+++ b/TODO
@@ -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