Hey Eugene,While it would seem pretty simple to do this, there are two reasons why the customers shouldn’t do this.We haven’t tested this internally, so we don’t know have the whole (clients, integrations etc) application works with this enabled. The licensing for the IFS MWS does not allow any configuration done to Middle Tier components without the use of IFS Tools. Another reason is that every time the Customer would take an UPD, MWS BP or an Oracle CPU from IFS, these settings would get overwritten by delivery. I understand the Customers requirements, but I strongly advise against doing this as it breaks the licensing agreement and the supportability of the product. Best RegardsMarkus
Hey everyone,IFS has now concluded an extensive assessment against all our supported products with result that none are found to be affected by the Spring4Shell (CVE-2022-22965) vulnerabilityBest RegardsMarkus Sandin - VP Infrastructure
Then my suggestion is that the Customer applies the latest Oracle CPU provided by IFS. That Oracle CPU contains patches for Log4J from Oracle. Best RegardsMarkus
Hey Eugene,Have they applied the latest Oracle CPU that was released by IFS a couple of weeks ago? Best RegardsMarkus
Hey,When we released IFS Cloud 21R1, it was our plan to support Hyper-V in 21R2. But those plans has changed and instead we have put Hyper-V on hold and will deliver a non-Virtual Appliance Solution. This solution will make it so that a clean Ubunutu 20.4 server is required as a prerequisite, then our setup-scripts will install and configure the things needed to deploy the Kuberenetes Middle Tier on this server. So for 21R2 the customer will able to choose between the VMWare-solution or the standalone Ubuntu-solution. Hope that answers your questions.One a side note - It’s technically possible to convert the OVA-file to a Hyper-V file but by doing that, we will not support that Hyper-V conversion and installation. Best RegardsMarkus
Hey Karim, I think you are referring to that the environemt you have is using Database Authentication. That is not the same as Basic Authentication With Database Authentication we are using the OpenID Connect/OAuth 2.0 authentication flow.
Hey, Projection endpoints that are exposed through the Main Application (as you can see in the Endpoint URL) utilizes OpenID Connect for authentication. And OpenID Connect utilizes OAuth 2.0, which means that you have to use the OAuth 2.0 option in POSTMAN. Please read through the POSTMAN Docs for this - https://learning.getpostman.com/docs/postman/sending-api-requests/authorization/#oauth-20 To properly set this up, you need to have access to some details in the OpenID discovery document. It resides at https://HOSTNAME/openid-connect-provider/.well-known/openid-configuration. But you also need extra information from the IFS Middleware Server Admin Console, as you need the Client ID and the Client Secret. Projections endpoints that are exposed through the Integration cluster utilize Basic Auth, so those are much simpler to utilize.
Hi again Jur,Unfortunately, that will not work. It’s not that simple Out of curiosity and to be able to help you better: What is that you are trying to achieve? What is the business case?Best RegardsMarkus
Hey,Assuming that you are on Apps10 - This is not possible. Database Authentication requires Identity and Directory ID to be exactly the same, else it will fail with the token verification. ALLOW_DB_AUTHENTICATION is associated with compatibility mode for Apps10. (Parts of the Apps9 authentication that was carried over to Apps10)Let me know if you have any further questions.Best RegardsMarkus
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
