Re: [DISCUSS] Token State Service implementation cleanup
Hi folks! The change is ready for review in GitHub: https://github.com/apache/knox/pull/826 Thanks, @Attilla Magyar for reviewing it already. I'd like to ask for at least one more from someone. Thanks! On Thu, Nov 30, 2023 at 12:03 PM Sandor Molnar wrote: > FYI: https://issues.apache.org/jira/browse/KNOX-2990 > > On Thu, Nov 30, 2023 at 9:05 AM Sandor Molnar > wrote: > >> Hello folks! >> >> After an offline discussion with Larry, we agreed on the following (as an >> extension to the action plan I listed above): >> - the migration tool will be run automatically when the Knox Gateway >> starts, and it will run on the main thread (i.e. not in the background). >> - there will be a config to control this step: in case of an error/bug, >> this automated migration could be turned off >> - when the first version of this newly configured DerbyDB JDBC TSS is >> implemented, I'll run some performance tests to see if encryption should be >> enabled by default >> - we'll make sure to protect the DerbyDB data folder with proper file >> permissions >> >> I'll submit the required JIRAs soon. >> >> Cheers, >> Sandor >> >> >> On Thu, Nov 23, 2023 at 11:59 PM larry mccay wrote: >> >>> If we can determine whether there is already an alias based TSS in place >>> and continue to use that for upgrades but derby for new clusters, I would >>> be in favor of that. >>> On whether to enable encryption, if we are only storing a hash of the >>> passcode token then that should be okay. >>> The persistence should be protected appropriately with file permissions >>> for >>> the knox user. >>> >>> NOTE: We will need to have some idea of how this may affect management >>> applications like Cloudera Manager and Ambari, if at all, and get out in >>> front of it. >>> >>> On Fri, Nov 17, 2023 at 8:27 AM Sandor Molnar >>> >>> wrote: >>> >>> > Hi folks! >>> > >>> > Let me try to summarize what we have so far: >>> > 1. we are all in favor of removing the JournalBased and Zookeeper TSS >>> > implementations >>> > 2. we all agreed that removing the AliasBasedTSS implementation >>> requires >>> > extra caution >>> > 3. Larry raised the following concerns >>> > 3.1 clear data storage in Derby -> ANSWER: Attila and I also >>> indicated >>> > Derby provides data encryption OOTB >>> > 3.2 token hashes -> ANSWER: we do not store JWTs, only metadata. We >>> > persist the passcode tokens though. It's hashed and stored using the >>> > "knox.token.hash.key" secret and "gateway.knox.token.hash.algorithm" >>> HMAC >>> > algorithm which defaults to HmacSHA256. >>> > 3.3 token synchronization across multiple Knox instances. -> >>> ANSWER: >>> > Derby has data replication capabilities. However, in HA environments, >>> I'd >>> > strongly recommend using Postgres/MySQL in those Knox instances >>> > 4. Sandeep and Phil articulated the importance of deprecation -> we all >>> > agree on this point >>> > 5. Phil asked whether data encryption should be the default in the >>> > Derby-configured JDBC TSS --> IMO, encryption should be turned on by >>> > default. The required "bootPassword" should be auto-generated and >>> stored in >>> > __gateway-credentials.jks >>> > 6. I recommended that the migration tool should be automated: when >>> token >>> > state service is initiated and it's using the pre-configured Derby >>> > database, we may check if there is any token stored in __gateway.jks >>> and >>> > migrate them. This way it'd be seamless for existing tokens. >>> > >>> > Action plan: >>> > - waiting for additional inputs on the above >>> > - implement the DerbyDB configuration using encryption >>> > - implement the migration tool in KnoxCLI and wire it in as a startup >>> step >>> > for the DerbyDB default implementation >>> > - make sure end-users will not need to change anything when switching >>> to >>> > the new DerbyDB configured JDBC TSS >>> > - make those three TSS implementations deprecated in v2.1.0, but leave >>> the >>> > AliasBasedTokenState service the default implementation >>> > - release v2.1.0 and document the changes in this area. It's crucial to >>> > emphasize we are going to remove them in the upcoming release >>> (v2.2.0?) and >>> > encourage end-users to switch to the DerbyDB JDBC TSS ASAP >>> > - once v2.1.0 is released, remove the deprecated implementations and >>> have >>> > the new DerbyDB JDBC TSS the default one >>> > >>> > As always, feel free to add your comments and insights on the above >>> > subject. >>> > >>> > Cheers, >>> > Sandor >>> > >>> > On Tue, Nov 14, 2023 at 3:41 PM Phil Zampino >>> wrote: >>> > >>> > > First and foremost, I'll echo the comments about deprecation. IMO, we >>> > must >>> > > deprecate these implementations in a release before completely >>> removing >>> > > them in a subsequent release. >>> > > >>> > > I agree that the ZK and Journal implementations should be deprecated >>> for >>> > > the reasons stated. >>> > > >>> > > Concerning replacing the alias-based implementation with Derby, I >>>
[jira] [Updated] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2994:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.5.0, 2.0.0, 1.6.0
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?focusedWorklogId=897973=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-897973
]
ASF GitHub Bot logged work on KNOX-2994:
Author: ASF GitHub Bot
Created on: 04/Jan/24 07:31
Start Date: 04/Jan/24 07:31
Worklog Time Spent: 10m
Work Description: smolnar82 merged PR #831:
URL: https://github.com/apache/knox/pull/831
Issue Time Tracking
---
Worklog Id: (was: 897973)
Time Spent: 20m (was: 10m)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.5.0, 2.0.0, 1.6.0
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802501#comment-17802501
]
ASF subversion and git services commented on KNOX-2994:
---
Commit bb6719f3cad33cc89c990a2ab5bc61756c497d4f in knox's branch
refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=bb6719f3c ]
KNOX-2994 - PollingConfigurationAnalyzer starts after the Knox GW is up and
running (#831)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.5.0, 2.0.0, 1.6.0
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] KNOX-2994 - PollingConfigurationAnalyzer starts after the Knox GW is up and running [knox]
smolnar82 merged PR #831: URL: https://github.com/apache/knox/pull/831 -- 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: dev-unsubscr...@knox.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[
https://issues.apache.org/jira/browse/KNOX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2994:
Status: Patch Available (was: Open)
> Postpone CM configuration change monitoring until the Knox GW is up
> ---
>
> Key: KNOX-2994
> URL: https://issues.apache.org/jira/browse/KNOX-2994
> Project: Apache Knox
> Issue Type: Improvement
> Components: cm-discovery, Server
>Affects Versions: 1.6.0, 1.5.0, 2.0.0
>Reporter: Sandor Molnar
>Assignee: Sandor Molnar
>Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now, Knox starts CM configuration change monitoring right away it
> starts the {{{}DefaultClusterConfigurationMonitorService{}}}. This action
> will trigger the {{PollingConfigurationAnalyzer}} even when descriptors with
> possible service discovery settings are not even initialized.
> My suggestion is to take advantage of the recently introduced
> {{GatewayStatusService}} and set the {{isActive}} flag to true based on the
> result of
> {{{}org.apache.knox.gateway.services.topology.impl.GatewayStatusService.status(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (KNOX-2994) Postpone CM configuration change monitoring until the Knox GW is up
[ https://issues.apache.org/jira/browse/KNOX-2994?focusedWorklogId=897886=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-897886 ] ASF GitHub Bot logged work on KNOX-2994: Author: ASF GitHub Bot Created on: 03/Jan/24 13:48 Start Date: 03/Jan/24 13:48 Worklog Time Spent: 10m Work Description: smolnar82 opened a new pull request, #831: URL: https://github.com/apache/knox/pull/831 ## What changes were proposed in this pull request? Actual cluster configuration change monitoring should not happen until the Knox Gateway is fully up and running and all the topologies are deployed. ## How was this patch tested? Updated existing unit tests and added a new test case to cover this new functionality. Apart from this, I also conducted an E2E test round on a live CM cluster (I set the `gateway.cluster.config.monitor.cm.interval` to `5` to make sure we see config monitor attempts every 5 seconds). After I restarted Knox I confirmed the feature is working: ``` 2024-01-03 12:55:15,551 INFO knox.gateway (GatewayServer.java:startGateway(389)) - Starting gateway... ... 2024-01-03 12:55:15,607 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(203)) - Started ClouderaManager cluster configuration monitor (checking every 5 seconds) 2024-01-03 12:55:15,607 INFO knox.gateway (GatewayStatusService.java:status(45)) - Checking gateway status. No topologies to check 2024-01-03 12:55:15,608 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:20,609 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] ... 2024-01-03 12:55:25,610 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] 2024-01-03 12:55:25,610 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:30,611 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] 2024-01-03 12:55:30,611 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:35,612 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [metadata, knoxsso, health, tokenexchange, homepage]. Waiting for: [cdp-proxy, cdp-proxy-token, manager, admin, kt-kerberos, cdp-proxy-api] 2024-01-03 12:55:35,612 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:40,613 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [metadata, manager, knoxsso, health, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage]. Waiting for: [cdp-proxy, cdp-proxy-token] 2024-01-03 12:55:40,613 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:45,613 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [cdp-proxy, metadata, manager, cdp-proxy-token, knoxsso, health, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage]. Waiting for: [] 2024-01-03 12:55:45,614 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:monitorClusterConfigurationChanges(234)) - Checking Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 for configuration changes... 2024-01-03 12:55:45,638 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:getRelevantEvents(465)) - Querying configuration activation events from Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 since 2024-01-03T12:55:21.944Z 2024-01-03 12:55:45,723 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:getRelevantEvents(474)) - There is no any activation event found within the given time period 2024-01-03 12:55:50,723 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:monitorClusterConfigurationChanges(234)) - Checking Cluster
[PR] KNOX-2994 - PollingConfigurationAnalyzer starts after the Knox GW is up and running [knox]
smolnar82 opened a new pull request, #831: URL: https://github.com/apache/knox/pull/831 ## What changes were proposed in this pull request? Actual cluster configuration change monitoring should not happen until the Knox Gateway is fully up and running and all the topologies are deployed. ## How was this patch tested? Updated existing unit tests and added a new test case to cover this new functionality. Apart from this, I also conducted an E2E test round on a live CM cluster (I set the `gateway.cluster.config.monitor.cm.interval` to `5` to make sure we see config monitor attempts every 5 seconds). After I restarted Knox I confirmed the feature is working: ``` 2024-01-03 12:55:15,551 INFO knox.gateway (GatewayServer.java:startGateway(389)) - Starting gateway... ... 2024-01-03 12:55:15,607 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(203)) - Started ClouderaManager cluster configuration monitor (checking every 5 seconds) 2024-01-03 12:55:15,607 INFO knox.gateway (GatewayStatusService.java:status(45)) - Checking gateway status. No topologies to check 2024-01-03 12:55:15,608 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:20,609 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] ... 2024-01-03 12:55:25,610 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] 2024-01-03 12:55:25,610 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:30,611 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [health]. Waiting for: [cdp-proxy, metadata, cdp-proxy-token, manager, knoxsso, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage] 2024-01-03 12:55:30,611 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:35,612 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [metadata, knoxsso, health, tokenexchange, homepage]. Waiting for: [cdp-proxy, cdp-proxy-token, manager, admin, kt-kerberos, cdp-proxy-api] 2024-01-03 12:55:35,612 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:40,613 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [metadata, manager, knoxsso, health, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage]. Waiting for: [cdp-proxy, cdp-proxy-token] 2024-01-03 12:55:40,613 INFO discovery.cm (PollingConfigurationAnalyzer.java:run(215)) - The Knox Gateway is not yet ready to monitor ClouderaManager cluster configuration changes. ... 2024-01-03 12:55:45,613 INFO knox.gateway (GatewayStatusService.java:status(50)) - Checking gateway status. Deployed topologies: [cdp-proxy, metadata, manager, cdp-proxy-token, knoxsso, health, admin, kt-kerberos, tokenexchange, cdp-proxy-api, homepage]. Waiting for: [] 2024-01-03 12:55:45,614 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:monitorClusterConfigurationChanges(234)) - Checking Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 for configuration changes... 2024-01-03 12:55:45,638 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:getRelevantEvents(465)) - Querying configuration activation events from Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 since 2024-01-03T12:55:21.944Z 2024-01-03 12:55:45,723 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:getRelevantEvents(474)) - There is no any activation event found within the given time period 2024-01-03 12:55:50,723 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:monitorClusterConfigurationChanges(234)) - Checking Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 for configuration changes... 2024-01-03 12:55:50,747 DEBUG discovery.cm (PollingConfigurationAnalyzer.java:getRelevantEvents(465)) - Querying configuration activation events from Cluster 1 @ https://ccycloud-1.smolnar.root.comops.site:7183 since 2024-01-03T12:55:35.639Z 2024-01-03 12:55:50,765 DEBUG discovery.cm
[jira] [Work logged] (KNOX-2990) TokenStateService implementation cleanup
[
https://issues.apache.org/jira/browse/KNOX-2990?focusedWorklogId=897819=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-897819
]
ASF GitHub Bot logged work on KNOX-2990:
Author: ASF GitHub Bot
Created on: 03/Jan/24 10:08
Start Date: 03/Jan/24 10:08
Worklog Time Spent: 10m
Work Description: smolnar82 commented on code in PR #826:
URL: https://github.com/apache/knox/pull/826#discussion_r1440274597
##
gateway-server/src/main/java/org/apache/knox/gateway/util/TokenMigrationTool.java:
##
@@ -0,0 +1,232 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.knox.gateway.util;
+
+import java.io.PrintStream;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Locale;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.knox.gateway.i18n.messages.MessagesFactory;
+import org.apache.knox.gateway.services.security.AliasService;
+import org.apache.knox.gateway.services.security.AliasServiceException;
+import org.apache.knox.gateway.services.security.token.TokenMetadata;
+import org.apache.knox.gateway.services.security.token.TokenStateService;
+import org.apache.knox.gateway.services.token.impl.TokenStateServiceMessages;
+
+public class TokenMigrationTool {
+
+ private static final String TOKEN_ALIAS_SUFFIX_DELIM = "--";
+ private static final String TOKEN_ISSUE_TIME_POSTFIX =
TOKEN_ALIAS_SUFFIX_DELIM + "iss";
+ private static final String TOKEN_MAX_LIFETIME_POSTFIX =
TOKEN_ALIAS_SUFFIX_DELIM + "max";
+ private static final String TOKEN_META_POSTFIX = TOKEN_ALIAS_SUFFIX_DELIM +
"meta";
+ private static final TokenStateServiceMessages LOG =
MessagesFactory.get(TokenStateServiceMessages.class);
+
+ private final AliasService aliasService;
+ private final TokenStateService tokenStateService;
+ private final PrintStream out;
+
+ private int progressCount = 10;
+ private boolean archiveMigratedTokens;
+ private boolean migrateExpiredTokens;
+ private boolean verbose;
+
+ public TokenMigrationTool(AliasService aliasService, TokenStateService
tokenStateService, PrintStream out) {
+this.aliasService = aliasService;
+this.tokenStateService = tokenStateService;
+this.out = out;
+ }
+
+ public void setProgressCount(int progressCount) {
+this.progressCount = progressCount;
+ }
+
+ public void setArchiveMigratedTokens(boolean archiveMigratedTokens) {
+this.archiveMigratedTokens = archiveMigratedTokens;
+ }
+
+ public void setMigrateExpiredTokens(boolean migrateExpiredTokens) {
+this.migrateExpiredTokens = migrateExpiredTokens;
+ }
+
+ public void setVerbose(boolean verbose) {
+this.verbose = verbose;
+ }
+
+ public void migrateTokensFromGatewayCredentialStore() {
+try {
+ final Map tokenDataMap = new ConcurrentHashMap<>();
+ final long start = System.currentTimeMillis();
+ String logMessage = "Loading token aliases from the __gateway credential
store. This could take a while.";
+ log(logMessage);
+ final Map passwordAliasMap =
aliasService.getPasswordsForGateway();
+ log("Token aliases loaded in " + (System.currentTimeMillis() - start) +
" milliseconds");
+ String alias;
+ for (Map.Entry passwordAliasMapEntry :
passwordAliasMap.entrySet()) {
+alias = passwordAliasMapEntry.getKey();
+processAlias(passwordAliasMap, passwordAliasMapEntry, alias,
tokenDataMap);
+ }
+
+ final long migrationStart = System.currentTimeMillis();
+ final AtomicInteger count = new AtomicInteger(0);
Review Comment:
No, there is no multi-threading here. I needed to use AtomicInteger because
of the stream below accepts a final `count` variable.
Issue Time Tracking
---
Worklog Id: (was: 897819)
Time Spent: 0.5h (was: 20m)
> TokenStateService implementation cleanup
>
>
> Key: KNOX-2990
> URL: https://issues.apache.org/jira/browse/KNOX-2990
Re: [PR] KNOX-2990 - Using DerbyDatabaseTSS instead of AliasBasedTSS by default [knox]
smolnar82 commented on code in PR #826:
URL: https://github.com/apache/knox/pull/826#discussion_r1440274597
##
gateway-server/src/main/java/org/apache/knox/gateway/util/TokenMigrationTool.java:
##
@@ -0,0 +1,232 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.knox.gateway.util;
+
+import java.io.PrintStream;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Locale;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.knox.gateway.i18n.messages.MessagesFactory;
+import org.apache.knox.gateway.services.security.AliasService;
+import org.apache.knox.gateway.services.security.AliasServiceException;
+import org.apache.knox.gateway.services.security.token.TokenMetadata;
+import org.apache.knox.gateway.services.security.token.TokenStateService;
+import org.apache.knox.gateway.services.token.impl.TokenStateServiceMessages;
+
+public class TokenMigrationTool {
+
+ private static final String TOKEN_ALIAS_SUFFIX_DELIM = "--";
+ private static final String TOKEN_ISSUE_TIME_POSTFIX =
TOKEN_ALIAS_SUFFIX_DELIM + "iss";
+ private static final String TOKEN_MAX_LIFETIME_POSTFIX =
TOKEN_ALIAS_SUFFIX_DELIM + "max";
+ private static final String TOKEN_META_POSTFIX = TOKEN_ALIAS_SUFFIX_DELIM +
"meta";
+ private static final TokenStateServiceMessages LOG =
MessagesFactory.get(TokenStateServiceMessages.class);
+
+ private final AliasService aliasService;
+ private final TokenStateService tokenStateService;
+ private final PrintStream out;
+
+ private int progressCount = 10;
+ private boolean archiveMigratedTokens;
+ private boolean migrateExpiredTokens;
+ private boolean verbose;
+
+ public TokenMigrationTool(AliasService aliasService, TokenStateService
tokenStateService, PrintStream out) {
+this.aliasService = aliasService;
+this.tokenStateService = tokenStateService;
+this.out = out;
+ }
+
+ public void setProgressCount(int progressCount) {
+this.progressCount = progressCount;
+ }
+
+ public void setArchiveMigratedTokens(boolean archiveMigratedTokens) {
+this.archiveMigratedTokens = archiveMigratedTokens;
+ }
+
+ public void setMigrateExpiredTokens(boolean migrateExpiredTokens) {
+this.migrateExpiredTokens = migrateExpiredTokens;
+ }
+
+ public void setVerbose(boolean verbose) {
+this.verbose = verbose;
+ }
+
+ public void migrateTokensFromGatewayCredentialStore() {
+try {
+ final Map tokenDataMap = new ConcurrentHashMap<>();
+ final long start = System.currentTimeMillis();
+ String logMessage = "Loading token aliases from the __gateway credential
store. This could take a while.";
+ log(logMessage);
+ final Map passwordAliasMap =
aliasService.getPasswordsForGateway();
+ log("Token aliases loaded in " + (System.currentTimeMillis() - start) +
" milliseconds");
+ String alias;
+ for (Map.Entry passwordAliasMapEntry :
passwordAliasMap.entrySet()) {
+alias = passwordAliasMapEntry.getKey();
+processAlias(passwordAliasMap, passwordAliasMapEntry, alias,
tokenDataMap);
+ }
+
+ final long migrationStart = System.currentTimeMillis();
+ final AtomicInteger count = new AtomicInteger(0);
Review Comment:
No, there is no multi-threading here. I needed to use AtomicInteger because
of the stream below accepts a final `count` variable.
--
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: dev-unsubscr...@knox.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
