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

Allow for a custom issuer in AuthN Request and custom issuer in AuthN Response. #2914

Open
jobannon opened this issue Nov 7, 2024 · 0 comments

Comments

@jobannon
Copy link

jobannon commented Nov 7, 2024

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 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.

Alternatives/workarounds

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)

  graph TD;
      SP(FA)-->Proxy;
      Proxy-->IDP;
      IDP-->Proxy;
      Proxy-->SP(FA);
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant