Federated Security Limitations

The M3 CloudSuites have been designed and tested to use a blend of basic authentication and federated authentication. Basic authentication is based on simple username and password and requires the use of Microsoft AD on the customer side. Federated authentication is based on SAML and requires the use of AD FS 3.0.

These are examples of products that use basic authentication. This is not an exhaustive list:

• Infor Smart Office
• M3 API Layer. This is legacy protocol that includes use by IEC and MEC.
• M3 Demand Planner
• M3 Scheduling Workbench. Note that client certificate authenticated use with the WebService API layer is possible.
• M3 Planning Workbench. Note that client certificate authenticated use with the WebService API layer is possible.
• Any client product accessible through Microsoft RDP or RDWeb, such as MEC Mapper and StreamServe/Exstream Control Center.

When using a federated authentication provider other than AD FS 3.0, such as Okta or Microsoft Azure AD FS, several components of the M3 CloudSuite will be unable to authenticate. This is because M3 relies upon the WS Trust endpoints that Microsoft AD FS 3.0 provides. These required endpoints are not provided by Okta or Microsofit Azure AD FS. Web Clients such as Ming.le and H5 for M3 do not require basic authentication and are not therefore impacted by this limitation.

The only supported scenario for use of a provider other than AD FS 3.0, is one where all those users who require access to the basic authentication products, are created and managed in the INFORBC domain. This is the domain that is hosted by Infor as part of the M3 CloudSuites. This will however result in a requirement for dual user management as the users will exist in either Okta or Microsoft Azure AD FS in addition to the INFORBC domains.