You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2020/06/12 01:32:00 UTC

[jira] [Work logged] (KNOX-2377) Address potential loss of token state

     [ https://issues.apache.org/jira/browse/KNOX-2377?focusedWorklogId=444669&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-444669 ]

ASF GitHub Bot logged work on KNOX-2377:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 12/Jun/20 01:31
            Start Date: 12/Jun/20 01:31
    Worklog Time Spent: 10m 
      Work Description: pzampino opened a new pull request #345:
URL: https://github.com/apache/knox/pull/345


   ## What changes were proposed in this pull request?
   
   With the resolution of KNOX-2375, the potential for token state to be lost between the issuance of a token and its persistence to the keystore. To address this risk, this patchset introduces a TokenStateJournal, the default implementation of which persists small individual files for each token's state until it is persisted in the keystore. This new facility has been integrated into the AliasBasedTokenStateService, which is the driver behind creating it. When token state it added, an entry (file) is added to the journal; Then, once that state has been persisted in the keystore, the journal entry (file) is removed since the risk of loss is no longer present.
   
   Part of the integration includes loading all the persisted token state journal entries when the AliasBasedTokenStateService is initialized, which effectively allows it to resume processing from where it has left off if the gateway was stopped or crashed after the addition of one or more tokens but before the state for those tokens could be persisted.
   
   ## How was this patch tested?
   
   - 'mvn -T1.5C -Ppackage,release clean install'
   - Added FileTokenStateJournalTest and MultiFileTokenStateJournalTest unit test classes
   - Augmented AliasBasedTokenStateServiceTest to test the integration of the TokenStateJournal with the AliasBasedTokenStateService, the intended (and only) consumer.
   - Manual testing involving two clients concurrently requesting tokens, and allowing this type of test to run through multiple token state eviction cycles, such that I feel there is no additional issue wrt thread-safety or performance.


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 444669)
    Remaining Estimate: 0h
            Time Spent: 10m

> Address potential loss of token state
> -------------------------------------
>
>                 Key: KNOX-2377
>                 URL: https://issues.apache.org/jira/browse/KNOX-2377
>             Project: Apache Knox
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.5.0
>            Reporter: Philip Zampino
>            Assignee: Philip Zampino
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the recent performance enhancements associated with token state management (KNOX-2375), there has come the possibility of token state getting lost.
> Part of the performance improvement is removing the persistence of token state to the keystore (which is expensive) from the token request processing path, and performing that persistence in a background thread.
> It's possible that the gateway could crash or otherwise go down before the state of recently-issued tokens has been persisted to the keystore. Consequently, after the gateway is restarted, subsequent use of these "lost" tokens would result in client authentication failures because the tokens would be unknown to the TokenStateService.
> The TokenStateService needs to be able to recover from such scenarios to avoid the loss of token state.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)