I've been tasked with integrating Fellow with our Azure Active Directory tenant to enforce SAML SSO for all engineering staff. Despite following the documentation and several iterations with their support, authentication consistently fails at the IdP (Azure AD) with a rather generic "AADSTS750056: A SAML response or a SAML assertion must be signed" error. My hypothesis is a misalignment in the cryptographic or endpoint configuration between the two systems, but I need community validation on my setup.
Our environment is a standard Azure AD tenant (not B2C) with the Enterprise Application configured for SAML 2.0. The Fellow-provided metadata was imported, and we've attempted both IdP- and SP-initiated flows. The critical configuration points we've set are:
* **Assertion Consumer Service URL:** ` https://app.fellow.app/auth/saml/callback`
* **Identifier (Entity ID):** ` https://app.fellow.app`
* **Reply URL:** Same as ACS URL.
* **RelayState:** Left blank.
* **Attributes & Claims:** We've mapped `user.mail` to `email` and `user.userprincipalname` to `user_id`.
* **Signing Certificate:** Using the auto-generated Azure AD certificate (not our own custom one). The signing option is set to "Sign SAML response and assertion."
On the Fellow side, the configuration is minimal:
* **SSO URL:** The Azure AD "Login URL" from the SAML setup page.
* **Issuer:** The "Azure AD Identifier" from the same page (typically ` https://sts.windows.net//`).
* **X.509 Certificate:** The base64-encoded certificate downloaded from Azure AD.
The failure is immediate upon redirection to Microsoft; the SAML request appears malformed or unsigned from Azure AD's perspective. I've examined the SAML request via browser developer tools, and the `SAMLRequest` parameter is present and deflate-encoded. A decoded example from a failed attempt shows:
```xml
<samlp:AuthnRequest ... IssueInstant="2023-10-26T19:01:00Z" Destination=" https://login.microsoftonline.com//saml 2" ...>
https://app.fellow.app
...
```
Key questions for those who have successfully navigated this integration:
1. Is the **Issuer** value in Fellow (` https://sts.windows.net/...`) expected to match the **Entity ID** configured in Azure AD (` https://app.fellow.app`), or should they be reciprocal? The documentation is ambiguous on this point, and in a standard SAML trust relationship, these are distinct entities.
2. Concerning the signature, does Fellow's SP metadata indicate it requires a signed SAML request? If so, Azure AD would need to be configured to "Sign SAML request," but that is typically not standard practice for SP-initiated flows. The error, however, explicitly states the *response* or *assertion* is not signed, which contradicts Azure's own "Sign SAML response and assertion" setting.
3. Has anyone had to implement a custom claim transformation or alter the `NameID` format to something other than `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`? I suspect the default `NameIdentifier` claim might be a point of contention.
I can provide sanitized logs and more detailed configuration snippets if needed. The goal is to establish a canonical, reproducible configuration for this integration, as the current trial-and-error approach is unsustainable.