summaryrefslogtreecommitdiffstats
path: root/custodia.conf
Commit message (Collapse)AuthorAgeFilesLines
* Add basic debugging capabilitiesSimo Sorce2015-06-051-0/+1
| | | | | | | If debug is set to True, then custodia's own Exception handlers will print a stack trace to standard output to aid debugging. Signed-off-by: Simo Sorce <simo@redhat.com>
* Add support for signed/encrypted messagesSimo Sorce2015-04-271-2/+15
| | | | | | | | | The new 'kem' type allows the backend to authorize access to keys based on a signed request where the key mus be whitelisted in advance in a kemkeys database. The reply is encrypted with the client public key. Signed-off-by: Simo Sorce <simo@redhat.com>
* Add Simple encrypted store.Simo Sorce2015-04-151-0/+18
| | | | | | | | | | | This uses JWCrypto to encrypt any key stored in the sqlite database with a master key. The master key is stored in a file and must be provided by the configuration. A sample key and configuration is provided too. Signed-off-by: Simo Sorce <simo@redhat.com>
* Move authz checks from Secrets to own classSimo Sorce2015-04-081-1/+11
| | | | | Add a Namespace authorization class to use in the pipeline instead of performing authorization within the Secrets class
* Add basic framework for authorization pluginsSimo Sorce2015-04-081-0/+4
|
* Change authenticators to return a resultSimo Sorce2015-04-071-4/+4
| | | | | | | | | Authenticators will not signal anymore validity by adding a request attributes. Instead they can return on of three values: - True, indicates positive authentication - False, indicate explicit failure - None, inicates neither success nor failure, not applicable
* Move Secrets class to its own fileSimo Sorce2015-04-061-0/+11
|
* Add simple secrets storage API to RootSimo Sorce2015-04-011-1/+0
| | | | | | | | | | | | | | This is a very simple implementation of a prototype API. Anyone that has access to the server and causes an authentication plugin to set the 'remote_user' value in the request, can retrieve and store secrets, Secrets are namespaced to the user requsteing them, so sharing secrets between multiple users is not possible. Secrets must to be of type "simple" and can only have one value. The value can be anything that can be reprsented in json format. It is recommended to pass a base64 encoded value.
* Make stores directly availble to consumersSimo Sorce2015-03-251-1/+1
|
* Adjust the code to be python3 happySimo Sorce2015-03-251-2/+2
| | | | | This required the renaming of the http directory to avoid clashes with the python3 own http/server module.
* Initial sinple store infrastructureSimo Sorce2015-03-251-0/+5
|
* Require positive authentication in all casesSimo Sorce2015-03-251-4/+4
| | | | | Provide a SimpleNULLAuth class for people that want to allow unauthenticated access fto specific paths for whatever reason.
* Add simple header auth moduleSimo Sorce2015-03-231-4/+9
| | | | | | | This is useful when authentication is handled by a proxy sitting in front of custodia. Alternatively it can be used with shared secrets/bearer tokens sent in plain text in the headers.
* Add basic authentication frameworkSimo Sorce2015-03-231-0/+5
| | | | | | This kicks in before any request is parsed at all. The whole request is provided so technically it can be as complex as wanted.
* Configure consumers via config fileSimo Sorce2015-03-231-0/+6
This is how new backends and mechanism can be defined on per-instance basis