-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Add exception metadata for disabled features #52811
Conversation
This change adds a new exception with consistent metadata for when security features are not enabled. This allows clients to be able to tell that an API failed due to a configuration option, and respond accordingly. Relates: kibana#55255 Resolves: elastic#52311
Pinging @elastic/es-security (:Security/Authentication) |
Ping @kobelb |
Ping @cjcenizal |
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 have some questions around the Feature
concept. Please see above (below actually). Thanks.
public enum Feature { | ||
TOKEN_SERVICE("security_tokens"), | ||
API_KEY_SERVICE("api_keys"); | ||
|
||
private final String featureName; | ||
|
||
Feature(String featureName) { | ||
this.featureName = featureName; | ||
} | ||
} |
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 wonder whether we should give Feature
more attention to make it more formalized, because it seems to be an useful concept for other places as well. By formalization, I mean something like, have it in a separate class, place it in a shared package which is more accessible, name each feature more consistently (more on this below).
Including Feature, we now have three different but related concepts: Feature, Setting, Plugin. Plugin seems to be the highest level, in that it provides one or multiple Features and Settings. I am not sure whether Feature has an 1-to-1 relationship with a Setting
. If so, I feel the associated Setting should be reflected in this class and this could be useful for users to act accordingly.
If the relationship between Feature and Setting is more complex, e.g. a feature corresponds to multiple Settings working together, it may need to be more carefully defined and promoted to be a first level concept. I am a bit surprised that Feature is not already an existing concept since both Setting and Plugin sound too technical when talking to users, while Feature seem to be a more accessible term.
I am aware that it is not something inherent to this PR so we don't need to solve it all with this PR. One possible actionable item is to move this class to a more common package for reuse by places other than security.
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.
Yes, no, maybe...
We do have "feature" concepts throughout the codebase. The obvious example being isXyzzyAllowed()
on XPackLicenseState. Those are, roughly speaking, features.
I can imagine a world when we had strong model of "Feature" and the license checks where all isFeatureAllowed(Feature feature)
, and elsewhere isFeatureEnabled(Feature)
, but we don't and I don't think anyone wants to.
The reason I added an enum here is
- So that the feature names were static & defined in a single place, so that clients could rely on the names being a well defined set (at least, per version).
- I could have solved that with constant Strings, but then the exception constructor would have been
(String, String, Object ...)
and there would be ambiguity about whichString
was the feature name and which was the message.
I think there's something to your suggestion, but progress over perfection - to me, this is a straight forward solution to the problem at hand, and we can evolve it into something else in the future if we need.
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.
Enum is good (at least for now). I agree that we don't wanna stall on something that is not in scope of the problem at hand. My actual question is whether we should move this file to a more common module, e.g. the xpack core
module for dependency sake, since I can see it being useful for other xpack modules besides security (similar to how license related files are in core
).
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.
My personal view, is that it's a false sense of "reuse".
As it stands:
- we don't know if this would be useful elsewhere. We can imagine places, but we have no plans to change them
- because of (1), we also don't know which enum values would make sense in the future
- we do know that future uses of it would be constrained by not being able to change it significantly because they'd risk breaking clients.
Based on the above, I understand the temptation to put it in core, but there's no clear value, and 1 definite limitation, so it seems like something that feels good for reuse purposes, but actually isn't.
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 was thinking about using it in the "role template validation" if we chose to issue warning instead of error out. Since we have decided it's ok to error out, I currently have no other idea where it could be re-used. So the current form is ok with me.
...plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/ApiKeyServiceTests.java
Show resolved
Hide resolved
.../plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/TokenServiceTests.java
Show resolved
Hide resolved
.../plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/TokenServiceTests.java
Show resolved
Hide resolved
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, sorry for the delay, I missed the notification.
Maybe update the PR description with a sample listing of the exception, it might save clients folks some time:
{
"error" : {
"root_cause" : [
{
"type" : "feature_not_enabled_exception",
"reason" : "security tokens are not enabled",
"disabled.feature" : "security_tokens"
}
],
"type" : "feature_not_enabled_exception",
"reason" : "security tokens are not enabled",
"disabled.feature" : "security_tokens"
},
"status" : 400
}
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
This change adds a new exception with consistent metadata for when security features are not enabled. This allows clients to be able to tell that an API failed due to a configuration option, and respond accordingly. Relates: kibana#55255 Resolves: elastic#52311, elastic#47759 Backport of: elastic#52811
This change adds a new exception with consistent metadata for when
security features are not enabled. This allows clients to be able to
tell that an API failed due to a configuration option, and respond
accordingly.
Relates: elastic/kibana#55255
Resolves: #52311, #47759
Sample REST output
For now, possible feature names are
security_tokens
andapi_keys