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:

• Delegation of authentication to an external service known as an Identity Provider, which presents the user with some means to authenticate securely.

• Transfer and validation of a token proving a successful authentication to IFS Middleware Server. The exact process for this varies slightly between clients.
• Mapping of the authenticated identity contained within the token to the corresponding Foundation1 user identity.

Contents

• User authentication
• User authentication architecture
• Application types
• Identity asserters
• Multi factor authentication

Related documents

• Authentication configuration

• System privileges
• Roles/Permission sets
• How application types map to different gateways

User authentication

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

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.

• The DEFAULT application type contains the main backend parts for use by graphical clients. This includes the IFS Client Gateway, the OData Provider used by the IFS Aurena client and similar things. It is set up to use OpenID Connect and regular users will generally make contact with these parts of the backend while running IFS Enterprise Explorer, IFS Aurena or any IFS Touch Applications.
• The B2B application type contains separate backend endpoints meant for business-to-business users running IFS Aurena. It uses OpenID Connect but only expose backend endpoints related to IFS Aurena. It is kept separate to enable the use of a different user registry from the non business-to-business users (such as the use of the Azure AD Business-to-Business Collaboration feature even if the rest of the users do not use Azure AD).
• The ADMINISTRATION application type contains alternate backend gateways for use with IFS Enterprise Explorer and IFS Touch Apps Server. It uses OpenID Connect but it is always configured to use the IFS Database Identity Provider and can not be reconfigured to use anything else. It is a fallback option for cases where work has to be done and access through Azure AD or ADFS is not possible. Examples of use may be to set up the first users to be able to log in using Azure AD or ADFS, access by an IFS technician lacking an AD account or system rescue in a case where the standard authentication process is unavailable due to some error.
• The COMPATIBILITY application type, also called INTEGRATIONS AND COMPATIBILITY, contains backend parts that do not use OpenID Connect (referred to as compatibility mode). It uses HTTP basic schemes as described above and is meant for integrations and development tools that can not use OpenID Connect. Integrations that happen using SOAP gateway also uses Basic authentication. It is recommended by IFS that these endpoints are not exposed to the Internet except through VPN.

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.