Configure Microsoft Entra ID SAML SSO
Who this is for
Microsoft Entra and Owlie administrators configuring an enterprise application for one Owlie tenant.
Goal
Register Owlie's SP values in Entra ID, import federation metadata, and complete a test login.
Prereqs
- Permission to create and assign an Entra enterprise application
- The SAML SSO overview
- A test user with an email in an Owlie allowed domain
Success criteria
Starting sign-in from Owlie redirects to Microsoft and returns an authenticated session to the initiating tenant.
Create the Entra enterprise application
- In Owlie, open Tenant Settings → Authentication → Login methods and copy the ACS URL and SP entity ID.
- In the Microsoft Entra admin center, open Enterprise applications → New application → Create your own application, then choose the option to integrate another application not found in the gallery.
- Open Single sign-on, choose SAML, and edit Basic SAML Configuration.
- Set Identifier (Entity ID) to Owlie's SP entity ID and Reply URL (Assertion Consumer Service URL) to Owlie's ACS URL.
- Under Attributes & Claims, make the unique user identifier an email value such as
user.mailwhen it is reliably populated; otherwise use the tenant's verified email-bearing claim and map it explicitly in Owlie. - Assign the test user or pilot group to the enterprise application.
Configure Owlie
- From SAML Certificates, copy the App Federation Metadata Url.
- In Owlie's SAML 2.0 panel, enable SAML SSO, set a Display label, add Allowed domains, and choose Metadata URL.
- Paste the URL and select Fetch metadata. In Confirm SAML metadata trust, compare current and incoming entity ID and SSO host, then verify every certificate's SHA-256 fingerprint, subject, and expiry. Owlie deliberately does not verify metadata signatures in v1.
- Select Confirm and save trust. Owlie re-fetches and refuses to save if the trust changed after preview. Map Email if the chosen Entra claim is not one of Owlie's defaults. Configure email trust and JIT, then select Save changes for any remaining edits.
- Test from
https://<tenant>.<root-domain>/auth/loginin a private window.
Default configuration
- Use the metadata URL and an email-valued NameID; leave other attribute mappings empty initially.
When to change it
- Map Entra's claim URI explicitly when the assertion does not expose the expected email/profile.
- Refresh metadata during Entra signing-certificate rollover. During an overlap, Owlie skips an unusable old certificate while a valid sibling remains usable.
Impact and risks
user.userprincipalnameis not always a routable email. Do not trust or allow it without checking the tenant's directory conventions.
Example
Create Owlie - Production, assign one pilot group, use user.mail for NameID, and allow only the
company's verified email domain during testing.
Troubleshooting
- AADSTS assignment error: assign the user or disable assignment requirements deliberately.
- Email missing/domain rejected: inspect the Entra claim selection and Owlie Email mapping.
- Signature failure after rollover: refresh metadata and confirm the new certificate is present.
- User rejected after link reset: with asserted-email trust disabled, Owlie will not automatically attach the assertion to an existing unlinked identity, and reset cannot merge a duplicate identity.
Assumptions & Questions
- Entra portal labels and the populated email attribute vary by tenant. Confirm both in a real test assertion before production rollout.