I would like to have a custom issuer value when using FusionAuth as the SP.
Use case
A customer may have many SAML v2 connections. A customer wants to migrate to FusionAuth, and many of those existing SAML v2 connections have a hard coded Issuer claim in the Authn Request, or in the AuthN response.
It may be useful to allow the Issuer that we send in the AuthN request to be modified to account for this use case.
Solution
Expose configuration to allow a custom issue to be set for the AuthN Request and allow this same issuer or alternates to be used on the AuthN response.
Similar behavior is possible in Auth0 using SAML v2 request templates.
If you were to only need to work around the Issuer validation when using a SAML v2 IdP initiated login workflow, where FusionAuth is attempting to validate the Issuer claim, you could in theory remove this from the SAMLResponse but to do that you'd have to validate the signature, remove the claim, or modify it, and then resign it with a different private key, and ensure FusionAuth has the public key.
In an SP initiated workflow, if your IdP wants a specific Issuer claim, you then would have to do the same thing by intercepting the request, validating the signature, and re-signing.
Specifically, this proxy would have to manage both the AuthN request and the AuthN response (resigning with the correct keys at to ensure the the proxy modified issuer has the correct public key and signature for the upstream IdP to verify)
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
Problem
I would like to have a custom issuer value when using FusionAuth as the SP.
Use case
A customer may have many SAML v2 connections. A customer wants to migrate to FusionAuth, and many of those existing SAML v2 connections have a hard coded
Issuerclaim in the Authn Request, or in the AuthN response.It may be useful to allow the
Issuerthat we send in the AuthN request to be modified to account for this use case.Solution
Expose configuration to allow a custom issue to be set for the AuthN Request and allow this same issuer or alternates to be used on the AuthN response.
Similar behavior is possible in Auth0 using SAML v2 request templates.
Alternatives/workarounds
If you were to only need to work around the
Issuervalidation when using a SAML v2 IdP initiated login workflow, where FusionAuth is attempting to validate theIssuerclaim, you could in theory remove this from theSAMLResponsebut to do that you'd have to validate the signature, remove the claim, or modify it, and then resign it with a different private key, and ensure FusionAuth has the public key.In an SP initiated workflow, if your IdP wants a specific
Issuerclaim, you then would have to do the same thing by intercepting the request, validating the signature, and re-signing.Specifically, this proxy would have to manage both the AuthN request and the AuthN response (resigning with the correct keys at to ensure the the proxy modified issuer has the correct public key and signature for the upstream IdP to verify)
Additional context
Customer Request
This policy would also align nicely with our existing alternate destinations policy.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.