• Home|
  • Blog|
  • Authentication, Authorization and Initialization in the OData API of IFS Cloud

Authentication, Authorization and Initialization in the OData API of IFS Cloud

June 27, 2023

Implementing OData service authentication may require custom HTTP Modules that can extend the default processing pipeline. In most known cases, developers will use an ASP.NET/IIS-based web application for hosting an OData service. Nevertheless, security authentication and authorization against incoming HTTP requests require infrastructure that combines more specific approaches. These will vary when it comes to certain specifics of each system provider.

Creating OData services hosted in the IFS environment have its exclusive complexity regarding customization server-side extension interfaces. We’ll introduce the IFS Cloud OData API service handling processes with regard to the authentication and authorization of the processes in default mode for IFS Cloud. We had the opportunity to interview our Novacura expert Albin Lundberg, Novacura Manager Flow Solution, an IFS Certified Practitioner – Supply Chain Consultant (IFS Cloud) – 2022. We briefly explain how to use the built-in extension object model OData Service to apply custom service authentication, authorization, and initialization, as well as how to handle the upgrades.

What are the different authentication options in IFS Cloud?

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 the IFS Platform and the configured Identity Provider(s). A part of the IFS Platform called the IFS Identity and Access Manager (IFS IAM) handles the authentication. This component is an OAuth2 authorization server that produces access tokens that can be used to access the backend API’s. It supports multiple OAuth2 flows which allow for different clients to authenticate in the manner which is appropriate to them. It can also be configured to handle a multitude of integration scenarios where a third-party app needs to get access.
Out of the box, the IAM maintains its own user registry which is kept in synchronization with the IFS user registry in the database. This user registry is used when authenticating users directly with the IFS IAM which is the default mode for IFS Cloud. In addition, external identity services can be used by configuring the IAM to delegate its authentication. This allows services such as Azure Active Directory to provide single sign-on as well as a familiar login experience to the users.

In prior versions of IFS Applications, an external system had to login to IFS and open a session using PLSQL APIs, to perform needed operations. Using REST ODATA APIs in IFS 10 you can use Basic Authentication. Is this no longer an option to Authenticate in IFS Cloud?

One option is to use Basic authentication. However, it is not recommended. Since you host your instances in the cloud, these are reachable to anyone on the web. Basic authentication can be configured but you need a technical person to do that. The only exception to use it would be when performing migrations of data or when you upgrade or set up your IFS instances. Do not use basic authentication when integrating IFS Cloud with 3rd party applications. In rare occasions, where you simply cannot use any other authentication than Basic Authentication, you can still use it with IFS Cloud, but only with Remote Deployment of IFS Cloud.

How is Authorization managed in IFS Cloud?

IFS Cloud has its own IFS Identity and Access Manager (IAM). The authentication is based on open standards to ensure the use of designs with well-known security characteristics. In order to learn more of the standards used, the following specifications provide a more detailed and in-depth explanation of the concepts:

  • The specification of the OAuth2 protocol.
  • The OpenID Connect specification.
  • The Bearer Token Usage specification (on how to provide access tokens to the backend from clients).
  • The OpenID Connect Discovery specification (on the format of the metadata document served by the IFS IAM to allow clients to communicate with it successfully).
  • The Proof Key for Code Exchange (PKCE) specification (on how to secure OAuth2 public clients such as native apps).

Requests heading into the system are checked for a valid access token from the IFS IAM on the IFS Proxy where all requests pass through in order to get access to the containers serving the IFS backend API’s. If the request lacks a valid access token from the IFS IAM there are two different ways for this to be handled. Browser requests can be redirected to the IFS IAM login page from the IFS Proxy, but many other clients do not respond to redirections and need to instead supply their own access tokens through other means. Both these ways of handling the authentication are possible.

No matter what way is used, the end result is an API request with an attached access token which the backend container can validate. Behind the IFS Proxy, all the authenticated HTTP requests appear the same and authentication is stateless.

In the previous PLSQL API, you had to use “IFS User” to log into IFS. Then every operation performed by an external system was performed on behalf of this user – with all positive consequences- IFS controlled access level and privileges in the same way as if the user would work directly in IFS. How is it handled now?

IFS Cloud differs in Authentication between End users and Service users. An End user will provide login credentials and the End user will have a set of permissions, much like it was configured before. The difference is that the Authentication and Access is managed by the IFS IAM Client instead of the Oracle permission, i.e. the projection permissions.
There are also service clients, so-called headless clients, representing applications interacting with IFS Cloud. This is equivalent to the use of the .net access provider in prior versions of IFS Applications. In IFS Cloud the configuration is instead done in the IFS IAM client.

48 Essential Questions About IFS Cloud Integration Answered!


Click to download a free .pdf

All Activities and Services have been replaced by RESTful OData APIs. How to handle upgrades and be sure that your IFS integrations are future-proof?

All activities and services (BizAPI’s) have been replaced.
.Net access provider is replaced. You can neither use the .Net Access provider nor any PL/SQL client to access the IFS Cloud. As permissions are handled on the Projections level you have to use REST ODATA to access the underlying PL/SQL views and methods (these are still the same).
The projections will change but the End Points will be kept. The safe way future proof your integrations will be to use the IFS Premium APIs (specifically provided by IFS to support Integrations). The set of Premium API’s are still limited and do not cover all of IFS Cloud. Hence, expect to create your own Premium API’s or enable the same as orchestrations in your integration middleware. When you do the orchestration in your middleware you need to call the same projections as the IFS Aurena client uses.
IFS will announce ahead of a functional release which API’s will be deprecated. You need to monitor this and analyze if you need to take action.

In PL/SQL, when you logged into IFS you were able to log in using a common user, and then switch users for the session using Oracle command (alter session). Is there some similar option in OData?

NO – it is not possible to do an impersonator command with REST OData.
The common user represents a Service user in IFS Cloud and there is no way of switching to an End User. You need to provide Authentication credentials as an End User in IFS Cloud.

In PL/SQL in the beginning you were able to initialize some session variables. I.e. you were able to set default local settings (some of date formatting, currency, language). How is it handled in OData?

Yes, exactly, or make sure it is already set up in IFS Cloud affecting the user properties.

Does this mean that , if you want to use a specific currency or date format, you need to pass it as an API call parameter each time instead of setting some session variable?

Some of these settings exist in the headers when you do the REST ODATA calls. This also related to the stateless nature of the OData API’s. Since, there is no session in the same sense as you had before. Now you do each call individually and IFS Cloud doesn’t track your previous calls. Some settings are connected to the user, like languages that can be controlled by the users and headers.

Summary

A role-based security model is commonly used for implementing authorization logic in service applications. So far, we have discussed several different options to apply authentication or authorization code logic for an IFS Cloud OData API service. As stated above, the OData service in IFS Cloud applies some custom authorization code logic to it. Knowing the aforementioned handler functions allows for determining general IFS Cloud OData API authorization logic. In this way, users can implement entity-set-specific access control.

Novacura supports customers in IFS Cloud to help them better assimilate with the IFS environment and their business requirements. Assisting with access control to better secure business operations is one the specific that is required in day-to-day operations. As a long-term partner of IFS, Novacura is providing complete IFS services from IFS implementation and support on a journey to IFS Cloud. Contact us today and see how we can support your organization.

INTERESTED IN LEARNING MORE ABOUT IFS CLOUD ODATA?

The article you are about to read is part of a broader series on the IFS Cloud OData API. Here's a link to the main article, which lists all the major barriers you may encounter when upgrading to IFS Cloud:

 

Introduction – barriers you can meet when moving to IFS Cloud and OData API

 

Below we present a whole list of articles belonging to the IFS Cloud OData series:

  1. The OData basics in the context of IFS Cloud
  2. How to replicate database transactions in OData for IFS Cloud
  3. Alternatives for OData in IFS Cloud
  4. Authentication, Authorization and Initialization in the OData API of IFS Cloud
  5. OData Efficiency with the remote cloud installation
  6. IFS customizations in OData
  7. Dealing With Legacy Systems
Contact our expert
Table of contents
The IFS Cloud REST OData API's in IFS 10 Authorization in IFS Cloud “IFS User” to log into IFS RESTful OData APIs Option in OData Initialize session variables Setting session variable Summary

Do you have a question?:

Please fill out this form