IFS vs SSO : what are the guideles to follow ?

Hi,

In a Multi-tenant Cloud environment, I currently only have feedback from a user management 100% managed by IFS.

So without using the SSO functionality via entity federation and the use of SAML v2.

What could you tell me as best practices or methods to follow for this configuration?
I have not been able to find any document explaining the steps to follow.
I know that this subject can become very technical from a security point of view and I am not an expert in this field.

But I think that the configuration should be able to be approached with a minimum of guidance.
For example, I wonder if it is possible to have user accounts governed by the AD (e.g. those of the client) and others not (e.g. consultant accounts only declared on IFS).

Thank you for sharing your thoughts.

Find more posts tagged with

Infor OS Portal

Accepted answers

Bart Conger

If a person is setup in IFS at startup, they can be controlled by external later.

Yes, if only IFS login/Mingle login, users should be given the URL for direct access as you identified, ?Identity=Mingle.

You define your default. It can be 'Federated Security' or 'Infor Mingle Identity' or which ever is established. Or you can select to allow the user to choose how to login. Definition of this is under IFS / Security Administration / Authentication URL Options.

If you setup a default login, i.e. federated, users can still have the option to choose their proper login by providing the URL, ?AuthMode=Prompt, which will display all possible login options. Then the user chooses their proper authentication path.

All comments

Denis MARETTE

Sorry : What are the guidelines to follow ?

Bart Conger

https://docs.infor.com/inforos/2022.x/en-us/inforoscsfcg/default.html

The link above can assist on the configuration in docs.infor.com, showing the supported federation.

You can utilize AD (ADFS / Okta / etc) for authentication to your domain.

If you have contractors that are not part of your domain they can be setup with a Ming.le / IFS only account. The password would be maintained within Infor IFS and not your AD. You can set the same/similar password rules in IFS as your AD for IFS only accounts. Your organization can also prevent IFS only accounts from changing their passwords, where you are required to set all passwords and then provide. It all depends on how much administration you want to do around IFS only accounts.

Hope this helps,

Barton

Kevin Heiman

The subject of SSO is about once a user is authenticated, what is the trust to all applications in the realm of the Portal. Portal SSO is providing that service making many applications available without reauthenticating.

What you are looking for is around User managment and that is covering the identity User provisioning/managment, and the authorizations of that user. IFS has a 'built-in' identity managment that you can use as you have been, however most organizatons perfer to federated to thier company identity provider giving them one place to mange authentication. That authentication adhears to company policies such at MutliFactor.

The federation(s) can be many of your choice. The account typically are provisioned into IFS with access entitlments usign SCIM or other interfacs. This allows the IFS to have the federated users externally managed. Infor GRC can alos be a layer for user provisioning, as well as the Infor HCM has an option to manager user as onborading, life evens, and separation occur.

If you manage a small population in IFS as infor identites, maybe contractors, you need to review the security policies and set those settings to represent your operational requirements. There are numersous options and general things should be tightened up vs relaxed. Limit users to a group or specfic list to access via Infor Identities, turn on MFA for Infor Identies, disable unused accounts, along with several password and user management policies.

Then you have service user accounts and associated service accounts that are created which need to be managed.

unknown

Hi Denis

we use SSO and SCIM with AzureAD

SCIM syncs and creates users, Roles get assigned by AD group, which is mapped to a role in IFS (and can be many to one, ie one ad group such as admin can get multiple admin roles in IFS)

This allows user access and permissions inside apps in cloudsuite to be managed by our service desk without them having to be IFS user admins

SSO is set up separately and I refer to that as "the front door keys", we have separate SSO apps for each environment.

the user is provisioned in PRD when they onboard, but they don't get the keys until they have been trained

The downside is the sync time from AD to Azure AD and then to IFS via SCIM, can take an hour or more sometimes (and you cant change the scim sync times)

Thanks,
George

Denis MARETTE

Thanks for the feedback. It's very interesting.
Indeed, to give the keys only once trained speaks to me because I worked a lot in the pharmaceutical laboratories. And it was one of the rules in force.

Denis MARETTE

Thank you for this overview of the different issues to be covered. It sets the framework for the reflection.
If I temporarily put aside the subject of IFS provisioning (because in my current context, there may not be that many users even if I understand the interest of this device) and focus only on the SSO aspect external to IFS, what would be the steps I need to follow to establish this relationship knowing that IFS will remain the authentication repository for the few users outside the customer's user directory? Thanks

Denis MARETTE

Hello Barton

Thank you for this summary which confirms what I thought.
I will take the time to study the referenced document to see how to order the actions to be done as logically as possible.
Is it possible that a person declared in IFS at startup can then be controlled by an external directory later?

Thanks

Denis MARETTE

Hi @congerb

I began to review the documentation outlining the process for establishing a trusted relationship with an identity provider. The step-by-step process is well described.

I have a little doubt: For users who would only have an IFS identity, does this mean that they should be given the URL that ends ?Identity=Mingle and for the other users (the vast majority) known to IFS and the identity provider, they log in by default with the URL that ends ?Identity=Federated.
And it is through this use of different URLs that these 2 populations cohabit.

Is my reformulation correct?

Thank you

Bart Conger

If a person is setup in IFS at startup, they can be controlled by external later.

Yes, if only IFS login/Mingle login, users should be given the URL for direct access as you identified, ?Identity=Mingle.

Copyright © 2025 Infor. All rights reserved.