[
https://issues.apache.org/jira/browse/KNOX-2624?focusedWorklogId=620696&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-620696
]
ASF GitHub Bot logged work on KNOX-2624:
----------------------------------------
Author: ASF GitHub Bot
Created on: 08/Jul/21 20:07
Start Date: 08/Jul/21 20:07
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request #461:
URL: https://github.com/apache/knox/pull/461
## What changes were proposed in this pull request?
A new Angular-based web UI is created to allow end-users to manage Knox
tokens created by the logged-in users. In order to make this happen, the
following changes were necessary:
**On the back-end side**
1. A new REST API endpoint had to be created to fetch Knox Tokens for the
logged-in user. A sample JSON response looks like this:
```
{
"tokens": [{
"tokenId": "e0aee0f0-dabb-4cc0-8133-37799c7d17da",
"issueTime": "2021-07-08T12:30:25.958+0200",
"expiration": "2021-07-08T13:30:25.955+0200",
"maxLifetime": "2021-07-15T12:30:25.958+0200",
"metadata": {
"enabled": true,
"userName": "guest",
"comment": "guest token"
}
}]
}
```
2. I'd to modify the `revoke` API to work with token IDs too: if the
submitted `token` is not an entire `JWT` but 'only' a token ID (which we have
available on the new token management UI) token revocation should work. In
fact, the current token state service only extracts the token ID from the
supplied JWT, so the token state service remains untouched in this respect;
only `TokenResource` had to be changed.
3. From now on, using `disabled` tokens on the verification side will result
in HTTP error `UNAUTHORIZED (401)`
**On the UI side**
1. There is a new link in the `General Proxy Information` section on the
Knox Home page that points to the new token management UI
2. A new token management UI is created using TypeScript and Angular2
**Updated configuration**
1. Enabled token state management in the `homepage` topology
2. Added `admin` as a renewer (so that it can revoke its own tokens)
3. `gateway.knox.token.eviction.grace.period` is set to `0` so that expired
tokens will be evicted w/o waiting for another day
## How was this patch tested?
Updated and executed JUnit tests.
I also tested the new functionality with `JDBCTokenStateSevice` and
`AliasBasedTokenStateService`.
Sample UI screenshot:
<img width="1653" alt="Screenshot 2021-07-08 at 21 52 50"
src="https://user-images.githubusercontent.com/34065904/124983079-cea9f500-e037-11eb-990b-ea852e42b96c.png";>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 620696)
Remaining Estimate: 0h
Time Spent: 10m
> Introducing token management page
> ---------------------------------
>
> Key: KNOX-2624
> URL: https://issues.apache.org/jira/browse/KNOX-2624
> Project: Apache Knox
> Issue Type: Improvement
> Affects Versions: 1.6.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It'd be greate to add management capabilities through a table that contains
> all of the tokens for the authenticated user.
> The Token Management page will contain a table of all active and disabled
> tokens for the authenticated user like this:
> |token-id|comment|created|expiration|status|actions|
> | | | | | | |
> Token actions may include:
> # Disable/Enable based on the current status
> # Revoke
> Actual tokens must not be rendered in the table and are only available for
> copying from the generation page. Since only hashes of the tokens are stored
> this is a hard requirement and a security best practice. If end-users lose
> access to their token, they should revoke it and generate a new one.
> Users may be limited to a maximum number of tokens each. This must be a
> configurable option and default to a reasonable default number that may be
> changed by an admin. This configuration must accommodate no limit as well but
> will not default to this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
![https://user-images.githubusercontent.com/34065904/124983079-cea9f500-e037-11eb-990b-ea852e42b96c.png"](https://user-images.githubusercontent.com/34065904/124983079-cea9f500-e037-11eb-990b-ea852e42b96c.png"){kind=link}