Status

Current state: In-progress

Discussion thread: 

JIRA: 

Motivation

There are a number of mostly incremental security improvements that should be made in order to allow for varying levels of hardening, crypto strength, token exchange/identity brokering, etc.
This KIP outlines what this set of improvements needs to be and some architectural and design choices - especially around token exchange and identity-brokering.

Improvements

1. Making Crypto Algorithms Configurable

  1. Make PBE Hashing, Iteration Count and Salt Configurable and Manageable (KNOX-944) DONE
  2. Make key sizes configurable for self-signed cert creation, etc
  3. Ensure that HTTPOnly and Secure flags are set on all cookies (KNOX-933) DONE
  4. Protect against LDAP Injection in the KnoxLdapRealm
  5. Ensure that the above improvements are backward compatible with deployed knox instances
  6. Ensure that the above configurable items are able to be configured prior to first start and the use of defaults (like in Ambari)
  7. SSOCookieProvider to be configurable for signature verification key/PEM (KNOX-947) DONE

2. Identity Broker APIs (KNOX-929)

  1. Ability to request a token on behalf of another user w/ cryptographically verifiable trust relationship. This is essentially an extension of the KnoxToken service where the username of the authenticated user is presented and the resulting token should represent that user rather than the requesting entity
  2. Ability to specify what type of token is being requested. There are use cases where Knox may be expected to interact with another STS service in order to acquire another token. This may need to be addressed as a separate REST resource and API or perhaps it can be a subtype of a more generic token response. Current KnoxToken API response looks something like:
{
"access_token":"eyJhbGciOiJSUzI1NiJ9.
                 eyJzdWIiOiJndWVzdCIsImF1ZCI6InRva2VuYmFzZWQiLCJpc3MiOiJLTk9YU1NPIiwiZXhwIjoxNDkzNTM4MjY1fQ.
                 FHsIdhlCi_h61PEXoKSbIEp5AlnVe9U5uEgcp7ktmVS8kLClFD2dj0KS-8sSnvNiPYdyZhEvxqNhjmhqXMd2YQz97O6FUSGf69_
                 lmarJPjz9K_6sDgrgpZnVQhUfHUG3k6-zetqzKZhu3gZYVLfu36TXb3C62TfXIrPF2qI9psM",
  "target_url":"https://localhost:8443/gateway/tokenbased",
  "token_type":"Bearer ",
  "expires_in":1493538265484
}

It is possible that the above could be used to represent multiple token types by adding additional token_type values for the client to interrogate and handle appropriately.

Of course, a client should request a token from a KnoxToken service that is configured to provide the desired token.

Perhaps, we limit an endpoint to a single token_type or we could configure a single service endpoint to service requests for certain types and rely on the client to ask for the desired one and default to current 'Bearer' type.

Where 'Bearer' implies our Knox JWT token.

Other potential types would include things like S3 or AWS tokens.

We may also want to consider base64 encoding the token for certain types.

Clients would have to know whether it needs to be decoded based on the type.

3. Shared Secret validator for Header based PreAuth Provider

Currently, Header based Preauth provider has IP address validation as the only built-in validator for establishing trust.

In addition, 2-way ssl can be used to establish trust at the gateway level. This also ensures that clients are trusted.

We should add a validator that verifies a signature based on a shared secret.

The secret must be provisioned on the Knox side as an alias in a credential store for protection.

4. JWTProvider to accept Query Param as well as Bearer Token (KNOX-938) DONE

As part of a some token exchange scenarios a special token may be acquired and used in a redirect URL to establish an SSO session.

This allows for redirection where headers are not guaranteed to be sent with the redirect and cookies may run into CORS related issues.

5. 2-way ssl must be able to use its own truststore rather than cacerts ALREADY DONE

Especially for trust relationships, we don't always want to trust just any client cert that has been issued by a trusted CA.

Therefore, we need to be able to specify exactly what clients we trust.

6. Group Lookup API

Instead of requiring every authorization point across the platform to configure LDAP information for

Hadoop Group Mapping needed for authorization checks, we can provide a central place to get the groups for a given user.

By providing this central API and add a client for it to the Hadoop Group Mapping we can help simplify configuration and

management of this necessary lookup across the entire platform.

 

 

 

 

  • No labels