AuthZ prod readiness

[c0c0n3]

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

• Extraction of KeyRock user JWTs through a configurable HTTP header—currently X-AUTH-TOKEN, but can be configured to be something else.
• More flexible & robust specification of AuthZ PDP URLs.
• Support for overriding DAPS & KeyRock JWT expiry through cache_decision_max_seconds—see caching below.

JWT

• Parsing of DAPS JWT custom claims: subject common name, security profile (with arbitrary entries), membership, scopes.
• Parsing of KeyRock JWT custom claims: application ID & AFZ domain, roles—including extraction of role names from organizations and roles structures.
• DAPS issuer validation. The connector ID in the DAPS headerissuerConnector field should be the same as the subject's common name in the DAPS token.
• Validation of HS 256 signatures.
• Robust validation of JWT 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-in jwt-go validation and makes sure we avoid the issues detailed in #14.

AuthZ

• Authorisation now takes into account all the following parameters:
  • DAPS connector ID, issuer, membership, scopes and security profile as found in the DAPS JWT contained in the IDS header.
  • Application ID, AZF domain and roles from the KeyRock JWT in the X-AUTH-TOKEN header.
  • FiWare service—content of fiware-service header.
  • Request verb and path.
• Robust building of XACML requests. A new, more type-safe DSL replaces the old, error-prone string manipulation machinery used to assemble XML payloads.

Caching

• Caching of KeyRock JWTs.
• Configurable caching of AuthZ decisions. An AuthZ decision gets cached for t seconds where t is the least of: consumer JWT expiry (computed from exp in DAPS token), user JWT expiry (computed from exp in KeyRock token), and the configured maximum in the adapter's config.

[c0c0n3]

@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!

[c0c0n3]

@gboege reviewed and tested (thanks!), so I'm merging this PR.