Closed c0c0n3 closed 4 years ago
@gboege if you could please check out the dev branch and do some sanity checking, following the updated instructions in the readme as usual. thanks a stack!
@gboege reviewed and tested (thanks!), so I'm merging this PR.
This mammoth PR should bring to an end (touch wood!) development of the feature set for AuthZ access control. That's basically all the additions and changes spec'd in #37 except for AuthZ authentication. Also, in the process we managed to fix #14.
In detail, this PR implements several features, broken down below according to functional areas.
Configuration
X-AUTH-TOKEN
, but can be configured to be something else.cache_decision_max_seconds
—see caching below.JWT
organizations
androles
structures.issuerConnector
field should be the same as the subject's common name in the DAPS token.nbf
/exp
claims. For a token to be valid, both conditions must hold true: (1)exp
isn't present or, if it is, specifies a date in the future; and (2)nbf
isn't present or, if it is, doesn't specify a date in the future. The implementation covers several corner cases we couldn't handle with built-injwt-go
validation and makes sure we avoid the issues detailed in #14.AuthZ
X-AUTH-TOKEN
header.fiware-service
header.Caching
t
seconds wheret
is the least of: consumer JWT expiry (computed fromexp
in DAPS token), user JWT expiry (computed fromexp
in KeyRock token), and the configured maximum in the adapter's config.