ring-api-key-middleware

No description

Find a file

Yann Esposito (Yogsototh) cd5d9bbf4d better wrap-fn		2017-11-07 17:07:53 +01:00
doc	Initial commit	2017-11-03 16:01:04 +01:00
src/ring_api_key_middleware	better wrap-fn	2017-11-07 17:07:53 +01:00
test/ring_api_key_middleware	Initial commit	2017-11-03 16:01:04 +01:00
.gitignore	Initial commit	2017-11-03 16:01:04 +01:00
CHANGELOG.md	Initial commit	2017-11-03 16:01:04 +01:00
LICENSE	Initial commit	2017-11-03 16:01:04 +01:00
project.clj	better wrap-fn	2017-11-07 17:07:53 +01:00
README.org	better wrap-fn	2017-11-07 17:07:53 +01:00

README.org

ring-api-key-middleware

https://travis-ci.org/threatgrid/ring-api-key-middleware.png?branch=master

`ring-api-key-middleware`

A simple middleware to authenticate users using API Key

Features

the function to check the validity of API Key should be provided and not part of this middleware.

Usage

Middleware & options

Use wrap-api-key-auth-fn to create an instance of the middleware, wrap your routes with it:

(defn get-auth-from-api-key [token]
    (when (= token "secret-api-key")
      {:user {:id "user-01" :name "username"}
       :groups #{{:id "cisco" :name "Cisco"}}
       :roles #{:admin :user}
       :auth-type :api-key}))

(def app
     ((wrap-api-key-auth-fn get-auth-from-api-key) handler))

When configured like this all requests with the header:

Authorization: apiKey secret-api-key

will be modified to be passed to the handler with the new key `:api-key-info` containing:

{:user {:id "user-01" :name "username"}
 :groups #{{:id "cisco" :name "Cisco"}}
 :roles #{:admin :user}
 :auth-type :api-key}

If the header contain an Authorization header with an unknown `api-key` the request will be rejected with a 403.

Authorization: apiKey unknown-api-key

If the header contain something with another authorization kind or no authorization header like:

Authorization: Bearer something-else

Then the request will be passed to the handler without any `api-key-info`. This provide the ability for other authentication middleware to be used. Deciding what to do about authenticated or non-authenticated user is left for another middleware or to be handled by the app handler.