# How to Set Up SAML Single Sign-On for Infor OS > Source: https://netray.co/erp-help/infor-os-saml-sso-federation-setup-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Infor OS can trust your corporate identity provider, such as Microsoft Entra ID or Okta, through SAML 2.0 federation. You exchange metadata between the two sides, map a stable identifier such as the email or user principal name to the Infor user, and then test with a pilot user before switching everyone over. ## Kind how-to ## System infor-os ## Erp Infor OS (Federation Services) ## Module Infor OS Portal / Identity ## Query how to set up SAML SSO with Azure AD or Okta for Infor OS ## Alternate Queries - Infor OS single sign on identity provider setup - Infor Federation Services SAML configuration - Infor OS SSO login loop fix - Infor Ming.le SSO Azure AD Entra ## Applies To Infor OS multi-tenant cloud with Infor Federation Services; on-premises deployments use Infor Federation Services or ADFS integration with similar concepts ## Steps ### Federate Infor OS with your identity provider **Items:** - Confirm who can perform the change. Federation is configured by Infor Cloud Operations or by a tenant administrator in Infor OS, depending on your contract, so raise a request if you cannot see the identity settings. - In your identity provider, create a new SAML 2.0 enterprise application for Infor and capture its metadata URL or XML, including entity id, sign-on URL and signing certificate. - Obtain the Infor service provider metadata for your tenant (entity id and assertion consumer service URL) and enter it in the identity provider application. - Choose the NameID or claim that identifies the user, normally the email or user principal name, and make sure the same value exists on the Infor user record as the federation or sign-in identifier. - Load the identity provider metadata on the Infor side, and set the mapping for the identifier attribute. - Assign a small pilot group in the identity provider and test sign-in in a private browser window from the Infor OS URL, then from the identity provider launcher. - Keep one break-glass local administrator, then move users in waves and watch the sign-in logs on both sides. ## Sections ### User matching is where most projects fail **Body:** SAML only proves who the identity provider says the person is. Infor still has to match that identity to an existing user, so the claim you send must equal the identifier stored in Infor, character for character. A mismatch of case, domain or alias typically produces an error page after a successful sign-in at the identity provider. Check the legacy accounts before the switch. Many tenants hold users created years ago with personal email addresses or shortened names, while the corporate directory uses a different format. Reconcile these with a spreadsheet export first, then update the Infor side in bulk rather than discovering mismatches one login at a time. ### Certificates and clocks **Body:** The signing certificate in the identity provider metadata expires, often after one to three years. When it rolls over and Infor still holds the old one, every sign-in fails with a signature validation message at the same moment. Put the expiry date in a calendar and replace the metadata before the date. SAML assertions are valid for a short window. Clock skew on an on-premises identity server can reject assertions as not yet valid or already expired, so keep time synchronised with an NTP source. ### Fixing login loops and downstream products **Body:** A loop between the Infor URL and the identity provider usually means the assertion is rejected silently, for example a wrong audience value, a missing NameID, or cookies blocked in an embedded frame. Capture the SAML response with a browser extension or the identity provider sign-in log and compare the audience and recipient values to the Infor metadata. Remember that single sign-on to the portal does not by itself create access in each product. M3, SyteLine, LN and other applications still need their own user and role setup, often synchronised from Infor OS security roles. Test an actual application launch, not only the portal landing page. ## Pitfalls - Sending a claim value that does not match the identifier stored on the Infor user, which yields an unknown user error after a successful sign-in. - Letting the signing certificate expire. Track the date and rotate metadata ahead of it. - Cutting everyone over with no local break-glass administrator in case federation fails. - Testing only the portal home page and not application launch, where role problems appear. - Ignoring service accounts. API service accounts do not use SAML and should stay as ION API service accounts. ## Ai Angle Identity is also what keeps AI honest. An assistant on top of Infor should inherit the signed-in user's roles, or run under a narrowly scoped service account, so SSO decisions flow through to what questions it can answer. ERPray respects ERP roles; with SAML in place, those roles map to real named people instead of shared logins, which makes its read-only query log meaningful. ## Faq ### Does Infor OS support SAML 2.0? **Answer:** Yes. Infor OS supports federation with SAML 2.0 identity providers such as Microsoft Entra ID, Okta and ADFS through Infor Federation Services. The details of who configures it depend on whether you are on the multi-tenant cloud or on premises. ### Why do users reach Infor but get an unknown user error? **Answer:** The identity provider authenticated them, but the claim sent to Infor does not match any Infor user identifier. Compare the NameID value to the user's federation identifier in Infor and fix case, domain or alias differences. ### Will SSO change how API integrations authenticate? **Answer:** No. ION API backend services keep using service accounts and OAuth tokens. SAML applies to people signing in interactively, not to scripts or middleware. ### What happens when the identity provider certificate expires? **Answer:** Sign-ins fail for everyone using that provider because the assertion signature cannot be validated against the old certificate. Load the renewed metadata on the Infor side before the old certificate expires. ## Search terms Infor OS SAML SSO, Infor Federation Services, Infor SSO Azure AD, Infor SSO Okta, Infor Ming.le single sign on, Infor OS identity provider, Infor SAML login loop, Infor user federation identifier, Infor CloudSuite SSO setup, Infor OS ADFS --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json