-
Notifications
You must be signed in to change notification settings - Fork 476
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
CredentialComposer plugin serializes integer claims as float #4982
Comments
Wanted to add that we distilled our composer plugin to:
and verified the timestamps were still float. The issue is in the implementation of the plugin model. This essentially makes integer claims impossible when using the plugin. |
I think the long term fix will involve changing the proto definition of Claims: |
Temporarily fixed with:
right before spire/pkg/server/credtemplate/builder.go Line 348 in 9e23dbe
|
…patiblity with AWS Using credentialcomposer plugins forces Claims to be translated as protobuf structs which serializes integers as floats (spiffe#4982). AWS rejects validating JWT issued by SPIRE with timestamps that are in scientific notation. AWS STS only accepts integer timestamps as valid. We've discussed this with AWS, and while they agree it's an issue in AWS STS, there's no recourse available with them. This fix helps reset value type for timestamps and also includes unit tests that make the problem obvious. This is the minimal change needed for SPIRE to produce verifiable JWT for AWS when using credentialcomposer plugin. Signed-off-by: narora@indeed.com
…patiblity with AWS Using credentialcomposer plugins forces Claims to be translated as protobuf structs which serializes integers as floats (spiffe#4982). AWS rejects validating JWT issued by SPIRE with timestamps that are in scientific notation. AWS STS only accepts integer timestamps as valid. We've discussed this with AWS, and while they agree it's an issue in AWS STS, there's no recourse available with them. This fix helps reset value type for timestamps and also includes unit tests that make the problem obvious. This is the minimal change needed for SPIRE to produce verifiable JWT for AWS when using credentialcomposer plugin. Signed-off-by: Nikhil Arora <narora@indeed.com>
…patiblity with AWS (#5115) Using credentialcomposer plugins forces Claims to be translated as protobuf structs which serializes integers as floats (#4982). AWS rejects validating JWT issued by SPIRE with timestamps that are in scientific notation. AWS STS only accepts integer timestamps as valid. We've discussed this with AWS, and while they agree it's an issue in AWS STS, there's no recourse available with them. This fix helps reset value type for timestamps and also includes unit tests that make the problem obvious. This is the minimal change needed for SPIRE to produce verifiable JWT for AWS when using credentialcomposer plugin. Signed-off-by: Nikhil Arora <narora@indeed.com>
Linux server-1 5.15.0-1053-aws #58~20.04.1-Ubuntu SMP Mon Jan 22 17:15:01 UTC 2024 x86_64 Linux
Problem: Using the composer plugin for modifying JWT-SVIDs yields in timestamp claims like
iat
,exp
etc. to be formatted as typefloat
. While numeric type is valid for timestamps and the the token can be successfully validated using jwt.io, AWS rejects it. I've already reached out to AWS support and they have asked us to fix the issue on our end.Here's a sample spire JWT-SVID payload when not using the composer plugin
Note,
exp
andiat
are integer.Here's a sample spire JWT-SVID payload when using the credential composer plugin (our plugin implementation never modifies those claims)
Note,
exp
andiat
are floats. Still valid JWTs and valid timestamps, but AWS SDK will reject the use of such JWT with:Upon initial investigation is looks like an issue with the proto definition of
Claims
. We believe it’s due to the following representation:Claims *structpb.Struct
The protobuf struct doesn’t support integers and prefers to represent numbers as double.
double number_value = 2;
The translations of Claims as protobuf Struct and then further JSON serialization is likely yielding the final format of
float
type.Goal: Stick to integer representation for well known timestamp claims for compatibility with AWS.
The text was updated successfully, but these errors were encountered: