Add telemetry around signature validation

This is a cherry pick from #3410 to dev8x

Original PR's description

This pull request introduces telemetry tracking for JWT and SAML/2 signature validation in the JsonWebTokenHandler and related classes. It refactors several methods to non-static to support instance-level telemetry. The changes enable detailed telemetry reporting on signature validation outcomes, such as missing keys, unsupported algorithms, and verification failures.

Telemetry integration for JWT and SAML signature validation:

• Added telemetry reporting to all major signature validation paths in JsonWebTokenHandler, SamlSecurityTokenHandler, and Saml2SecurityTokenHandler, capturing events like signing key not found, algorithm not supported, signature provider creation failure, and signature verification failure or success. This is accomplished by calling the new RecordSignatureValidationTelemetry helper at appropriate points.
• Refactored ValidateSignature, ValidateSignatureUsingAllKeys, and ValidateSignatureWithKey methods from static to instance methods, allowing access to the instance telemetry client (_telemetryClient).
• Updated the signature validation logic to pass the telemetry client through the call stack, ensuring telemetry is recorded for all signature validation attempts, including when using all keys or a specific key.

These changes lay the groundwork for comprehensive telemetry on signature validation, improving observability and diagnostics for token validation scenarios.

New Telemetry Counter

Signature Validation Counter

The counter tracks 5 dimensions (tags):

Tag Cardinality Breakdown

1. IdentityModelVersion

• Cardinality: Low (~5-10 active versions)
• Values: Semantic versions (e.g., "7.3.1", "8.0.0")
• Typical Production: 1-3 versions during rollouts
• Lifecycle: Reduces over time as deployments converge

2. Algorithm

• Cardinality: ~12-15
• Possible Values (from JWT/SAML specs):

• Typical Production: 2-5 algorithms (commonly RS256, ES256, PS256)
• Bounded: JWT/JOSE specs define a finite set of algorithms

3. KeyAlgorithm

• Cardinality: ~11-13
• Implementation: CryptoTelemetry.GetKeyAlgorithmId(SecurityKey) returns predefined constants
• Possible Values:

• Typical Production: 3-6 key types (commonly RSA-2048, RSA-4096, ECDSA-P256)
• Bounded: Fixed set of industry-standard key sizes

4. Issuer

• Cardinality: Low (~5-20 tracked hosts)
• Implementation: CryptoTelemetry.GetTrackedIssuerOrOther(issuer) with allowlist-based filtering
• Behavior:
  • Extracts host from issuer URI (e.g., https://login.microsoftonline.com/tenant/ → login.microsoftonline.com)
  • Returns host if in CryptoTelemetry.TrackedIssuers allowlist
  • Returns "other" for all non-allowlisted issuers
• Typical Values:
  • login.microsoftonline.com (Microsoft Entra ID)
  • accounts.google.com (Google)
  • appleid.apple.com (Apple)
  • other (catch-all for non-tracked issuers)
• Cardinality Control: Allowlist prevents unbounded growth from arbitrary issuers
• Default: Empty allowlist (all issuers reported as "other")

5. Error

• Cardinality: 6 fixed values
• Implementation: TelemetryConstants.SignatureValidationErrors.*
• Possible Values:

• Typical Production: 2-4 error types observed (commonly None, SignatureVerificationFailed, SigningKeyNotFound)
• Bounded: Fixed set of error constants to prevent cardinality explosion

Total Cardinality Calculation

Total Combinations = IdentityModelVersion × Algorithm × KeyAlgorithm × Issuer × Error
                   = 5 × 15 × 13 × 20 × 6
                   = 117,000 theoretical maximum (with full issuer allowlist)

Production Reality (Empty Issuer Allowlist - Default):

Active Versions × Active Algorithms × Active Key Types × Issuer ("other" only) × Active Errors
= 2 × 4 × 4 × 1 × 3
= 96 typical active time series

Production Reality (With 5 Tracked Issuers):

Active Versions × Active Algorithms × Active Key Types × (Tracked Issuers + "other") × Active Errors
= 2 × 4 × 4 × 6 × 3
= 576 typical active time series

Upper Bound Estimate:

• Default (no issuer tracking): ~150-250 time series
• With issuer tracking (5-10 issuers): ~1,000-2,000 time series

Note: The issuer dimension is strictly controlled via the CryptoTelemetry.TrackedIssuers allowlist, preventing unbounded cardinality growth.

Cardinality Assessment

✅ Low-Medium Cardinality - Safe for production at scale

Rationale:

1. ✅ Issuer dimension is strictly allowlist-controlled (default: all issuers → "other")
2. ✅ Error dimension is a fixed enumeration (6 values)
3. ✅ Algorithm set is finite and standardized
4. ✅ Key sizes are industry-standard values (not arbitrary)
5. ✅ Library versions naturally consolidate over time

Benchmarks

For loop 100_000 calls + 10 OperationsPerInvoke

No for loop, 100_000 OperationsPerInvoke

• Remove TelemetryConfiguration enum from benchmarks; update benchmark attributes and tracked issuer values for consistency.
• Refactor and expand CryptoTelemetry tests: remove host extraction tests, consolidate key algorithm ID tests, and add more scenarios for tracked issuer matching and allowlist filtering.
• Update API documentation to reflect field renaming.
• Overall, unify telemetry client usage and streamline issuer tracking logic, with tests updated to match new behavior.

• Removed case insensitive comparison for telemetry issuer extraction based on PR feedback

(cherry picked from commit 61449b853c3ce153aa2a21ed75d5a9bc27af37cf)

Originally posted by @iNinja in AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#3415