-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KNOX-2990 - Using DerbyDatabaseTSS instead of AliasBasedTSS by default #826
Conversation
dd15602
to
263f4e2
Compare
26c4012
to
e1c54f0
Compare
gateway-server/src/main/java/org/apache/knox/gateway/util/TokenMigrationTool.java
Show resolved
Hide resolved
gateway-server/src/main/java/org/apache/knox/gateway/config/impl/GatewayConfigImpl.java
Outdated
Show resolved
Hide resolved
} | ||
} else if (matchesImplementation(implementation, DerbyDBTokenStateService.class, true)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking if this is a default impl then in almost all the cases this will be used. Do you think it will speed up knox startup if we move this to the top, it might be a sub milli-sec improvement :) so feel free to ignore this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make that change anyway and move theDerbyDBTokenStateService
so that the list starts with the default
implementation (naming is not our friend here :) ). I may also rename DefaultTSS
to InMemoryTSS
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is something about this logic that smells bad to me. From my point of view, someone should be able to implement TokenStateService with whatever impl they need, configure it in gateway-site, and drop their JAR in the ext dir. With this logic, that won't work. Can we consider refactoring this to keep Knox extensible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pzampino good point, service loader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The service loader approach is already in use by org.apache.knox.gateway.services.GatewayServiceFactory
. Thus, if someone wants to add their own implementation without contributing here, in the Knox project, they can do that by overriding the existing TokenStateServiceFactory
and having that custom factory inserted into the org.apache.knox.gateway.services.ServiceFactory
file within their custom JAR.
However, I see that's a different discussion we should start in Knox's DEV e-mail list. As of now, all service implementations work that way and I would rather not do this work in the scope of this JIRA.
Any objection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's create a JIRA improvement issue to address the extensibility conversation. With that, I agree we can exclude that from the scope of this specific work.
...-server/src/main/java/org/apache/knox/gateway/services/factory/TokenStateServiceFactory.java
Show resolved
Hide resolved
...r/src/main/java/org/apache/knox/gateway/services/token/impl/AliasBasedTokenStateService.java
Show resolved
Hide resolved
...rver/src/main/java/org/apache/knox/gateway/services/token/impl/DerbyDBTokenStateService.java
Outdated
Show resolved
Hide resolved
...rver/src/main/java/org/apache/knox/gateway/services/token/impl/DerbyDBTokenStateService.java
Show resolved
Hide resolved
...src/main/java/org/apache/knox/gateway/services/token/impl/JournalBasedTokenStateService.java
Show resolved
Hide resolved
} | ||
} else if (matchesImplementation(implementation, DerbyDBTokenStateService.class, true)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is something about this logic that smells bad to me. From my point of view, someone should be able to implement TokenStateService with whatever impl they need, configure it in gateway-site, and drop their JAR in the ext dir. With this logic, that won't work. Can we consider refactoring this to keep Knox extensible?
...-server/src/main/java/org/apache/knox/gateway/services/factory/TokenStateServiceFactory.java
Show resolved
Hide resolved
...-server/src/main/java/org/apache/knox/gateway/services/factory/TokenStateServiceFactory.java
Show resolved
Hide resolved
...rver/src/main/java/org/apache/knox/gateway/services/token/impl/DefaultTokenStateService.java
Outdated
Show resolved
Hide resolved
...-server/src/main/java/org/apache/knox/gateway/services/token/impl/JDBCTokenStateService.java
Show resolved
Hide resolved
gateway-server/src/main/java/org/apache/knox/gateway/util/TokenMigrationTool.java
Outdated
Show resolved
Hide resolved
In addition to the new implementation I deprecated the AliasBased, Zookeeper and JournalBased TSS implementations in 2.1.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
What changes were proposed in this pull request?
Implemented the changes I listed in KNOX-2990:
$DATA_DIR/security/tokens
(this time it's not yet encrypted)700
(only the owner can access it)TokenStateServiceFactory
to the new DerbyDatabaseTSSgateway-site.xml
properties:gateway.knox.token.migration.skip
: ensures that the previous automated step can be controlled (E.g. in case of unforeseen errors it can be turned off). Defaultsgateway.knox.token.migration.archive.tokens
: indicates if migrated tokesn should be archived in another credential store called__tokens
. Defaults tofalse
.gateway.knox.token.migration.include.expired.tokens
: whether expired tokens should be migrated or skipped. Defaults tofalse
.gateway.knox.token.migration.verbose
: if true, migrated/skipped tokens are added in the[gateway|knoxcli].log
and, optionally, on the STDOUT (when running the KnoxCLI tool manually). Defaults totrue
, because it's very useful to have the chancee to cross-reference token IDs in case of error debugging.gateway.knox.token.migration.progress.count
: the number of tokens after the token migration tool displays progress in the logs and, optionally, on the STDOUT.How was this patch tested?
Configured Knox to have the
AliasBasedTSS
as the token state backend and to allow unlimited token creation:Generated 456 tokens with random expiration times (456x4=1824 aliases) then stopped the Knox GW (to avoid the reaper thread removing expired tokens).
Executed the new KnoxCLI command to confirm it only migrates anything if the configured backend allows token migration:
Before running the new KnoxLCI command again, I commented out the
gateway.service.tokenstate.impl
param ingateway-site.xml
=> the new default, DerbyDBTSS, was in place.Executed the command again:
Repeated the generate/migration step, but this time without token archival:
I also tested the token migration tool integration during the Knox Gateway startup. I removed the previously created data/security/tokens folder, switched to AliasBasedTSS and created another 456 tokens. Then switched back to the default DerbyDBTSS and started the Knox GW. I confirmed the
$SECURITY_DIR/tokens
was created with the proper file permissions:I also checked if the automated token migration tool works as expected: