fix: ensure correct SAML Entity ID in client SSO flow

[timkendrick]

When initiating a SAML client flow via the /sso endpoint, the service provider object Entity ID is omitted from the initialization options, causing the underlying saml library to incorrectly use the metadata URL for the SAML server as the Entity ID.

This causes some service providers (e.g. Microsoft Entra ID) to reject the SAML authentication request, as the inferred supabase auth server metadata URL does not match the provider's Entity ID.

This change ensures the service provider is correctly initialized with the provider Entity ID during the client auth flow, while retaining the existing behavior for the server metadata endpoint.

[timkendrick]

Explanation of existing incorrect behavior:

Existing service provider instantiation does not pass the EntityID option:

auth/internal/api/saml.go

Lines 43 to 50 in 9a8d0df

	provider := samlsp.DefaultServiceProvider(samlsp.Options{
	URL: *externalURL,
	Key: a.config.SAML.RSAPrivateKey,
	Certificate: a.config.SAML.Certificate,
	SignRequest: true,
	AllowIDPInitiated: idpInitiated,
	IDPMetadata: identityProvider,
	})

...which leaves opts.EntityID empty in the underlying DefaultServiceProvider instantiation:

https://github.com/crewjam/saml/blob/346540312f721498fc75e69637d9250dd89f230b/samlsp/new.go#L132-L149

...so the Entity ID is incorrectly inferred as MetadataURL:

https://github.com/crewjam/saml/blob/346540312f721498fc75e69637d9250dd89f230b/service_provider.go#L71-L72

[hf]

The entityDescriptor here already should include the EntityID, maybe extract it from there instead?

[timkendrick]

Thanks for the review @hf - makes sense, this was my initial instinct as well.

I made the entityID argument explicit because we currently only pass the EntityDescriptor when we're in 'client mode' (i.e. authenticating with an external provider).

This function also happens to be invoked when exposing the SAML metadata endpoint ('server mode'), in which case we want to retain the existing behavior (inferring the metadata URL).

I've updated my fix to extract the identityProvider.EntityID only if there was an identityProvider provided, falling back to the previous 'inferred metadata URL' behavior if it is nil (as it is when this function is called from the SAMLMetadata endpoint).

[coveralls]

Pull Request Test Coverage Report for Build 18756420374

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 4 of 5 (80.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.002%) to 67.549%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/api/samlacs.go	0	1	0.0%

Totals
Change from base Build 18655410402:	0.002%
Covered Lines:	13447
Relevant Lines:	19907

---

💛 - Coveralls

[timkendrick]

I've addressed your feedback @hf - let me know if there's anything else I can do to help get this over the line :)