oauth actually has 3 different types of possible authentication types:
with username & password
with client credentials
with username & password & client credentials
okta has 2 different types:
with client credentials
with username & password & client credentials
zen currently only has 1 (with username & API key) but there are plans to include more.
Each of these authentication types should have their own unique auth modes, to better differentiate the expected inputs needed.
In addition, the secure flag, which pre-dates the introduction of auth_mode acts as an additional layer of auth detection. When secure is True, the auth mode is active but when secure is False, the auth mode is redundant.
This can be better implemented by removing secure and adding a no auth value to auth mode.
When a TNCOEnvironment is created, the properties are validated based on the auth mode. This does not cover the fact that properties can be changed later, potentially creating an invalid TNCOEnvironment. This may result in unexpected and unclear behaviour when a client is built from the TNCOEnvironment.
The properties should be validated when they are used to build a client instead. Validation on construction of a TNCOEnvironment should be optional, to allow for properties to be populated after initial construction, something we already use to allow sensitive data to be omitted and prompted for instead.
Currently we have the following auth modes:
oauthactually has 3 different types of possible authentication types:oktahas 2 different types:zencurrently only has 1 (with username & API key) but there are plans to include more.Each of these authentication types should have their own unique auth modes, to better differentiate the expected inputs needed.
In addition, the
secureflag, which pre-dates the introduction ofauth_modeacts as an additional layer of auth detection. Whensecureis True, the auth mode is active but whensecureis False, the auth mode is redundant. This can be better implemented by removingsecureand adding ano authvalue to auth mode.When a TNCOEnvironment is created, the properties are validated based on the auth mode. This does not cover the fact that properties can be changed later, potentially creating an invalid TNCOEnvironment. This may result in unexpected and unclear behaviour when a client is built from the TNCOEnvironment.
The properties should be validated when they are used to build a client instead. Validation on construction of a TNCOEnvironment should be optional, to allow for properties to be populated after initial construction, something we already use to allow sensitive data to be omitted and prompted for instead.