Major Description
The cookie used in KnoxSSO contains an underlying JWT token to represent the authentication event and the audiences for which it is valid.
This feature will allow an API client to directly request a Knox access token based on the configured authentication provider for the token service. This will essentially allow a client to exchange HTTP basic credentials for an access token that can be used until it expires.
There are a number of usecases for this token format for direct API access:
1. Through the use of a related CLI command for acquiring a token, KnoxShell scripts or programs can collect the token with a new required CredentialCollector from the user's home directory and issue REST API requests using it as a Bearer token credential. This allows the user to only provide initial credentials to the knox login CLI and have an SSO session based on the token until expiration. Similar to kerberos kinit with user credentials.
2. Similarly, headless, scheduled scripts and programs can run using this same sort of credential in more of a kerberos keytab manner. Meaning, the token has a very long or never expiring lifetime. OPEN QUESTION: keytabs are invalidated when the user's password changes - how do we provide such an out-of-band invalidation?
3. There may also be webapp usecases for access token use.
Will need to have complementing JIRAs for knox login CLI, KnoxToken credential collector and to add a federation provider that accepts the access token as a bearer token.