Skip to content
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

SAMLv2 Identity Provider - RelayState MUST NOT exceed 80 bytes #2467

Open
konvergence opened this issue Sep 14, 2023 · 5 comments
Open

SAMLv2 Identity Provider - RelayState MUST NOT exceed 80 bytes #2467

konvergence opened this issue Sep 14, 2023 · 5 comments
Labels
architecture Feedback on designed behavior saml standards Issues that refer to IETF, W3C or other standards working as designed

Comments

@konvergence
Copy link

SAMLv2 Identity Provider - RelayState MUST NOT exceed 80 bytes

Description

Non conformance with https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes
In "HTTP POST Binding" mode, the size of RelayState is shorter that in "HTTP Redirect Binding" mode but the size is more than 1100 characters

Affects versions

all and latest : 1.47.1

Steps to reproduce

Steps to reproduce the behavior:

  1. Create an SAMLv2 Identity provider with POST in the options
  2. On IdP side limit the size authorized RelayState header ( with a WAF for example)
  3. try a SAML request

Expected behavior

Why Fusionauth use a RelayState , specially in POST mode ?
Is there a way to reduce the RelayState to not exceed 80 chars ? specially in POST mode ?

Screenshots

If applicable, add screenshots to help explain your problem.

Platform

  • fusionauth : 1.47.1

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

Additional context

  • exemple of base64 encoded RelayState into the POST Binding Request
Y2xpZW50X2lkPWQ2NmQ2ZTc0LTkxZDctNDdhMS1hNDNiLThjMGE3OWVjYzVlZCZjb2RlX2NoYWxsZW5nZT1BVGptVHo1QVVDbGtYVF96NnMzelBwVG12d0JDM2RQaENScDN5bXN6Z0pvJmNvZGVfY2hhbGxlbmdlX21ldGhvZD1TMjU2Jm1ldGFEYXRhLmRldmljZS5uYW1lPVdpbmRvd3MlMjBDaHJvbWUmbWV0YURhdGEuZGV2aWNlLnR5cGU9QlJPV1NFUiZub25jZT0mcmVkaXJlY3RfdXJpPSUyRnNhbWx2MiUyRmNhbGxiYWNrJTJGMzc1NjhmYTQtOWE0YS00NmIyLWE0NDEtODMzMmNlNGY0M2YzJnJlc3BvbnNlX21vZGU9JnJlc3BvbnNlX3R5cGU9Y29kZSZzY29wZT0mc3RhdGU9ZXlKaFkzTWlPaUpvZEhSd2N6b3ZMM1JsYzNRdFozQndMWE5yYVhCd1pYSXVhM05vZFhSMGJHVXVhVzh2VkVWVFZDNVhaV0pUWlhKMmFXTmxMMkZqY3lJc0ltRnBJam9pWkRZMlpEWmxOelF0T1RGa055MDBOMkV4TFdFME0ySXRPR013WVRjNVpXTmpOV1ZrSWl3aWFXUWlPaUpmTXpnd1pUTTFNR05oTkRjeE56VTVZemhsTWpNeU1USmpNbU0zTnpBMFlUQTNPVEF6TWpFMk55SXNJbTVtSWpvaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TVM0eE9tNWhiV1ZwWkMxbWIzSnRZWFE2WlcxaGFXeEJaR1J5WlhOeklpd2ljbk1pT2lJdlZFVlRWQzVYWldKVFpYSjJhV05sTDI5dWJHbHVaUzhpZlElM0QlM0QmdGVuYW50SWQ9Mzc1NjhmYTQtOWE0YS00NmIyLWE0NDEtODMzMmNlNGY0M2YzJnRpbWV6b25lPUV1cm9wZSUyRlBhcmlzJnVzZXJfY29kZT0mY3NyZj1EQl91YWxEZkRGUHFiVGFfJmlkZW50aXR5UHJvdmlkZXJJZD1lZTY2OTAyMi0zMjRhLTQ1ZjgtODA2Yy00ODk0NTk1OWYwZTE
  • decoded RelayState
client_id=d66d6e74-91d7-47a1-a43b-8c0a79ecc5ed&code_challenge=ATjmTz5AUClkXT_z6s3zPpTmvwBC3dPhCRp3ymszgJo&code_challenge_method=S256&metaData.device.name=Windows%20Chrome&metaData.device.type=BROWSER&nonce=&redirect_uri=%2Fsamlv2%2Fcallback%2F37568fa4-9a4a-46b2-a441-8332ce4f43f3&response_mode=&response_type=code&scope=&state=eyJhY3MiOiJodHRwczovL3Rlc3QtZ3BwLXNraXBwZXIua3NodXR0bGUuaW8vVEVTVC5XZWJTZXJ2aWNlL2FjcyIsImFpIjoiZDY2ZDZlNzQtOTFkNy00N2ExLWE0M2ItOGMwYTc5ZWNjNWVkIiwiaWQiOiJfMzgwZTM1MGNhNDcxNzU5YzhlMjMyMTJjMmM3NzA0YTA3OTAzMjE2NyIsIm5mIjoidXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6ZW1haWxBZGRyZXNzIiwicnMiOiIvVEVTVC5XZWJTZXJ2aWNlL29ubGluZS8ifQ%3D%3D&tenantId=37568fa4-9a4a-46b2-a441-8332ce4f43f3&timezone=Europe%2FParis&user_code=&csrf=DB_ualDfDFPqbTa_&identityProviderId=ee669022-324a-45f8-806c-48945959f0e
@mooreds mooreds added bug Something isn't working standards Issues that refer to IETF, W3C or other standards saml labels Sep 14, 2023
@robotdan robotdan added working as designed architecture Feedback on designed behavior and removed bug Something isn't working labels Sep 15, 2023
@robotdan
Copy link
Member

Thanks for opening this issue @konvergence .

This looks to be working as designed. The SAML spec is old, and I don't know that anyone enforces this limitation. Are you opening this issue because FusionAuth is not functioning with another service provide due to this length, or are you just stating that we are creating a RelayState parameter greater than 80 bytes?

@konvergence
Copy link
Author

konvergence commented Sep 16, 2023

The saml provider that i need use, apply the limit of 80 characters on the relaystate.

He justify this limit with the SAML spécification.
He can derogate until 1024 but not more .

If i understand your design, you use relaystate to keep some fusionauth contexts. But from a point of view of SAML exchanges there is no reason to do it.

May be you could manage some contexts into server side sessions instead of to put them in the realystate.

Anyway at these step this is a breaking point for us.

@robotdan
Copy link
Member

Thanks for the additional detail @konvergence.

FusionAuth is currently using the value encoded in the RelayState to preserve context through this workflow. It may be possible we could build some alternate mechanism to do this in order to reduce the length of the RelayState value.

Can you share what IdP you are attempting to integrate with that is enforcing this limit?

@konvergence
Copy link
Author

The IdP is an internal DEV of a Bank. So I can't give you a Product or a doc .
If possible, may be I can give you an access on it

@konvergence
Copy link
Author

Hi,
Sorry, we can not give access to the IdP.
Could you give us a roadmap for an alternative mechanism in order to reduce the length of the RelayState value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Feedback on designed behavior saml standards Issues that refer to IETF, W3C or other standards working as designed
Projects
None yet
Development

No branches or pull requests

3 participants