User Authentication

All calls to the backend system will require authentication. Graphical clients authenticate using the OAuth 2 Authorization Framework and the OpenID Connect Authentication protocol which is built upon it. The authentication process is handled by IFS Middleware Server and the configured Identity Provider(s).
This process consist of three separate steps:


Related documents

User authentication

OpenID Connect schematic

The user authentication process is supervised by IFS Middleware Server and the user must be vouched for by an Identity Provider before the call even reach the IFS Applications backend. All calls from clients pass a security interceptor known as an Identity Asserter in the application server before the call reaches the IFS backend server code. Thus, all such calls are intercepted and all users are authenticated by an Identity Provider before the call can continue.

OAuth2 and OpenID Connect is the supported way for clients to authenticate to the backend. A number of Identity Providers are supported for use with these means of authenticating. Currently supported Identity Providers are the integrated IFS database Identity Provider , Azure AD and Active Directory Federation Services (ADFS) for Windows Server 2016 (earlier versions of ADFS do not support OpenID Connect and as such will not work).

If authentication is succesful, the second security layer is reached - Activity authorization. In this layer the call to the method is intercepted again in order to check if the called activity/service/projection is granted to the authenticated user. If true, the call proceeds to the actual implementation, otherwise a security exception preventing the user from calling the method is thrown.

User authentication architecture

Authentication architecture diagram.

The main clients of IFS Applications use OAuth2 and OpenID Connect in order to authenticate users as described above. For these, a choice can be made which one of the supported Identity Providers to delegate authentication to. An option exists to use a separate Identity Provider for Business to Business users, so that they may authenticate using another user registry than the rest of the userbase. Aside from this, there is an alternate endpoint which can be used for administration purposes, should the Identity Provider be down. This endpoint always delegates to the integrated IFS Database Identity Provider for user authentication.

Authentication for web services and integration projections exposed using IFS Connect, SOAP Gateway and the Integration OData Provider is handled by the application server in a different way compared to interactive clients. Services are configured for username/password authentication using the HTTP Basic scheme. This type of user authentication is referred to as compatibility mode throughout the documentation. Production builds of graphical clients developed by IFS are not built to use this type of authentication, as it is intended to be used by integrations and development tools that can't support OpenID Connect.

The credentials are not included in the SOAP XML message or the OData request, but are instead included in the HTTP Authorization header field.

Two forms of HTTP Basic authentication are available for compatibility mode. Either LDAP is configured and enabled on the application server (enabling the use of Active Directory or Azure AD Domain Services for compatibility mode as well as for OpenID Connect), or the IFS Database is used as the user registry for compatibility mode authentication. The integration with Windows Integrated Authentication present in earlier versions of IFS Applications is not available starting with IFS Applications 10, although ADFS and Azure AD can be configured to enable Single Sign On.

Application types

In order to support multiple authentication methods for different clients and users, the application backend has several different gateways into the system. The groupings of backend functionality resulting from this division are referred to as application types throughout the documentation.

Identity asserters

The authentication process is controlled by specialized components in the IFS Middleware Server called Identity Asserters. Each OpenID Connect enabled application type has an identity asserter assigned to it. The purpose of this component is to store configuration parameters and runtime information about the Identity Provider associated with it, relay this information to the clients to enable them to authenticate as well as validate the tokens issued by the identity provider and allow authenticated backend access to clients which can present acceptable tokens. Configuring the Identity Asserters can be done in the IFS Middleware Server Admin Console where they are referred to by their associated application type, and it is these components that control which identity providers are used.

Multi factor authentication

ADFS and Azure AD Identity providers support multi factor authentication where additional parameter(s) will be requested from the user during authentication in addtion to the user name and password. No additional configuration is required on IFS Applications to support multi factor authentication, but either ADFS or Azure AD must be used as the Identity Provider for such requirements.