-
Notifications
You must be signed in to change notification settings - Fork 870
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
Capture enduser attributes in Spring Security #9777
Capture enduser attributes in Spring Security #9777
Conversation
...on/spring/security/config/v6_0/webflux/SpringSecurityConfigWebFluxInstrumentationModule.java
Outdated
Show resolved
Hide resolved
d0245b5
to
d74065f
Compare
Looking for input on how to fix the failing muzzle verification. |
d74065f
to
03b568e
Compare
Figured it out. Needed to add a few |
Looking for opinions on the flags. I want the ability to control whether each enduser attribute is captured. There are a couple approaches of doing that. Approaches:Approach A (which is currently implemented in this PR)
Approach B (alternative)
Use Cases:Use case 1: Enable all
|
03b568e
to
8aa5b21
Compare
Adds library and javaagent instrumentation for spring-security-config to capture `enduser.*` semantic attributes. The library instrumentation provides: * a Servlet `Filter` and a WebFlux `WebFilter` to capture `enduser.*` semantic attributes from Spring Security `Authentication` objects. * `Customizer` implementations to insert those filters into the security filter chains created by `HttpSecurity` and `ServerHttpSecurity`, respectively. The javaagent instrumentation applies the `Customizer` implementations in the `build()` methods of `HttpSecurity` and `ServerHttpSecurity`. The automatic instrumentation is disabled by default, due to the following requirement in the specification: > Given the sensitive nature of this information, SDKs and exporters > SHOULD drop these attributes by default and then provide a > configuration parameter to turn on retention for use cases where the > information is required and would not violate any policies or > regulations. Since this requirement is common to any automatic instrumentation that captures `enduser.*` attributes, the following new common configuration properties are introduced: * `otel.instrumentation.common.enduser.enabled` - default false. Whether to capture `enduser.*` semantic attributes. Must be set to true to capture any `enduser.*` attributes. * `otel.instrumentation.common.enduser.id.enabled` - default true. Whether to capture `enduser.id` semantic attribute. Only takes effect if `otel.instrumentation.common.enduser.enabled` is true. * `otel.instrumentation.common.enduser.role.enabled` - default true. Whether to capture `enduser.role` semantic attribute. Only takes effect if `otel.instrumentation.common.enduser.enabled` is true. * `otel.instrumentation.common.enduser.scope.enabled` - default true. Whether to capture `enduser.scope` semantic attribute. Only takes effect if `otel.instrumentation.common.enduser.enabled` is true. In addition, the following new spring-security specific configuration properties are introduced: * `otel.instrumentation.spring-security.enduser.role.granted-authority-prefix` default `ROLE_`. Prefix of granted authorities identifying roles to capture in the `enduser.role` semantic attribute. * `otel.instrumentation.spring-security.enduser.scope.granted-authority-prefix` default `SCOPE_` Prefix of granted authorities identifying scopes to capture in the `enduser.scopes` semantic attribute.
8aa5b21
to
82c6dd9
Compare
can you describe a bit about why you want this level of control? do you think this is a general need? thx |
In my particular case, I do not want We also don't particularly care about I expect others to have similar use cases. |
thanks, that makes sense, Approach B seems good to me as it optimizes this use case, and is less complex compared to opt-in + opt-out |
Ok. I agree. I started leaning that direction after trying to document Approach A. Hah. I'll convert this PR to Approach B |
I've switched the PR over to Approach B and rebased on main, and all checks are passing. This PR is now ready for review. |
This brings the flag name into alignment with open-telemetry#9777
instrumentation/spring/spring-security-config-6.0/javaagent/README.md
Outdated
Show resolved
Hide resolved
...on/spring/security/config/v6_0/servlet/SpringSecurityConfigServletInstrumentationModule.java
Outdated
Show resolved
Hide resolved
...on/spring/security/config/v6_0/servlet/SpringSecurityConfigServletInstrumentationModule.java
Show resolved
Hide resolved
.../io/opentelemetry/instrumentation/spring/security/config/v6_0/EnduserAttributesCapturer.java
Outdated
Show resolved
Hide resolved
Any chance this can get merged for a November release? |
instrumentation/spring/spring-security-config-6.0/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
instrumentation/spring/spring-security-config-6.0/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
...ntation/spring/security/config/v6_0/servlet/EnduserAttributesCapturingServletFilterTest.java
Outdated
Show resolved
Hide resolved
instrumentation/spring/spring-security-config-6.0/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
to give spans time to be exported
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.
a couple of questions about otel.instrumentation.spring-security.enduser.role.granted-authority-prefix
(and similar for scopes)
- why only report the suffixes for matched roles? I think reporting the full role for matches will be clearer on the resulting telemetry (since consumers of the telemetry won't know the prefix used)
- why not
otel.instrumentation.common.enduser.role.granted-authority-prefix
? (or maybe justotel.instrumentation.common.enduser.role.prefix
)
Excellent questions. The short answer is that the prefix/suffix logic is to compensate for how roles and scopes are modeled as granted authorities in the spring security implementation. Now for the long answer... To explain, consider an OAuth scope named Roles are similar. A granted authority named And since the Regarding the configuration property names... The prefix/suffix concept is specific to spring security's granted authority implementation. Since this is spring-security specific, the configuration values should be prefixed with |
thanks! one more question
do we need to expose |
Spring Security allows the user to use different granted authority prefixes. Unfortunately, I could not find a way for the instrumentation to definitively determine if the user has configured spring security to use a different prefix. Therefore, I had to fallback on allowing the user to configure the prefix that OTel looks for via an OTel config property. |
Adds library and javaagent instrumentation for spring-security-config to capture
enduser.*
semantic attributes.The library instrumentation provides:
Filter
and a WebFluxWebFilter
to captureenduser.*
semantic attributes from Spring SecurityAuthentication
objects.Customizer
implementations to insert those filters into the security filter chains created byHttpSecurity
andServerHttpSecurity
, respectively.The javaagent instrumentation applies the
Customizer
implementations in thebuild()
methods ofHttpSecurity
andServerHttpSecurity
.The automatic instrumentation is disabled by default, due to the following requirement in the specification:
Since this requirement is common to any automatic instrumentation that captures
enduser.*
attributes, the following new common configuration properties are introduced:otel.instrumentation.common.enduser.id.enabled
false
enduser.id
semantic attribute.otel.instrumentation.common.enduser.role.enabled
false
enduser.role
semantic attribute.otel.instrumentation.common.enduser.scope.enabled
false
enduser.scope
semantic attribute.In addition, the following new spring-security specific configuration properties are introduced:
otel.instrumentation.spring-security.enduser.role.granted-authority-prefix
ROLE_
enduser.role
semantic attribute.otel.instrumentation.spring-security.enduser.scope.granted-authority-prefix
SCOPE_
enduser.scopes
semantic attribute.