Skip to main content

Hi,

When testing the connection in IFS Cloud (24R2) to PSO (24R2), it keeps failing. Upon initial configuration, the following error appeared. 

 

“Failed to connect to IFS Optimization server account Default. Error message was: 403 - Forbidden. The user IFSSCHEDULING and the parameters OpenIdAuthority, OpenIdClientId, UserNameClaim may need to be set up manually. Do you want to continue?”

 

I’ve reviewed other community posts that had similar errors and they were able to resolve it by whitelising the IP addresses. 

 

I’ve checked with the customer and they said that the environments are running on the same server and able to ping each other successfully. 

 

Are there any other issues during setup that can cause this error? In PSO, the parameters are blank. 

 

Here is a suggestion that ​@roklde gave in an internal chat:

 

That typically indicates an issue with the IAM Clients and/or IFSSCHEDULING and/or PSO Admin User. Try to re-configure the connection from scratch. Frist disable all active datasets and then disconnect the configuration. If that fails, go into PSO and clean the parameters OpenIdAuthority and OpenIdClientId. Further, remove the IFSSCHEDULING User. Delete IAM Clients IFS_automation, IFS_scheduling. Re-run the optimization assistant config and let it create the IAM client again.

 

Note: Before doing all of that make sure to set AllowAuthenticationGateway to true and have the PSO Administrator account details at hand! This will still give you direct access to PSO via the backdoor basic authentication login page at https:///IFSPSOWorkbench/Default/login?authGateway=true

 

The IFS_scheduling IAM client setup should look like this:

 


Hi Anthony,

are you sure that the configured PSO URLs are correct? For PSO on-premise and Azure deployments the URLs are:

https://<full-qualified-domain-name>/IFSSchedulingRESTfulGateway
https://<full-qualified-domain-name>/IFSPSOWorkbench

For Kubernetes deployments:
https://<full-qualified-domain-name>/pso/gateway
https://<full-qualified-domain-name>/pso/workbench

Best regards
Roman


Hi ​@Alexander Heinze,

I followed the steps of disabling the datasets, deleting the IFSSCHEDULING user, removing IAM clients IFS_automation and IFS_Scheduling. 

In PSO, the parameters OpenIDAuthority and OpenIDClientId are empty. No values were inputted for the fields. 

The error still appears however when I rerun the configuration and the Test Connection continues to fail. 

@roklde, customer is on-premise and we can access PSO using - https://<full-qualified-domain-name>/IFSPSOWorkbench

 

Best,

Anthony 


We will check further with customer as the PSO environment is now down and if there are any firewall issues. 


Do you see the 404 message when browsing to https://<full-qualified-domain-name>/IFSSchedulingRESTfulGateway ? If yes, that’s fine. 

Seems like the IFS Cloud Server can’t reach PSO. So, as you said, check Firewall settings etc.

 

Best regards
Roman


Was an issue with the network. 

Thanks. 


Hi, 

We're having trouble configuring PSO on IFS Cloud 24r2. When we try to change the configuration, we get the following error:

Screen1

What we have:

  1. PSO Workbench works:

Screen2

  1. In the application messages we have the following:

Screen3

  1. Error details

Screen4

  1. We know that this is the host where PSO is located, but the first message says there is a problem with the link:

https://psocfg.xxxxxx.pl/IFSSchedulingRESTfulGateway/api/v1/scheduling/session

but these links do not open even locally on the server where PSO is installed:

screen5

  1. On Ubuntu and Oracle we have open communication with the PSO server:

Screen6

  1. IAM Client :

Screen7

Has anyone had a similar problem and if so, how did you solve it?

 

 


Hi ​@Daniel, it seems that your IFS Cloud environment still isn’t able to find the PSO Server. Maybe it’s an issue with your DNS setting inside Kubernetes? You could try to make a connection from one of the IFS Cloud pods, e.g. ifsapp-connect or ifsapp-odata to the PSO Server. If that works than it’s something else causing the issue.

The errors you get when opening the relevant URLs on the PSO Server are to be expected.

 

Best regards
Roman

 


Hi ​@Daniel, it seems that your IFS Cloud environment still isn’t able to find the PSO Server. Maybe it’s an issue with your DNS setting inside Kubernetes? You could try to make a connection from one of the IFS Cloud pods, e.g. ifsapp-connect or ifsapp-odata to the PSO Server. If that works than it’s something else causing the issue.

The errors you get when opening the relevant URLs on the PSO Server are to be expected.

 

Best regards
Roman

 

Hi, ​@roklde thank you very much. Problem was on kubernetes DNS. Now we have connection but problem is with user:

 

IAM Client configuration is here:

 

 

Is this a configuration issue below or is it something on the PSO server side?

 


@Daniel do you have a second url set for ifs cloud? or is it the default dummy value (https://<FQDN>)? You can check that in the system parameters. if it’s the dummy value, you’ll have to redeploy the middletier by setting a valid secondary url (you can also use the same url as in system url). afterwards re-run the assistant to configure the connection.

 

Best regards

Roman


@roklde secondary url updated:

 

and error is the same (401 - bad auhorization)

 

I think there is something wrong with the data filled in below because when I perform the "change configuration" operation, the field below is overwritten with the value of "client_id" (circled field) even though I had previously entered IFS_scheduling there:

 

 


Please check the User and Password provided for the PSO Administration Account inside the Assistant. Also make sure that this User is active in PSO.

The Client Id in the Routing Address is fine. It’s a placeholder for the actual used Client Id.

Best regards

Roman

 


The problem was with the route addresses and rules, where I was changing the client_id parameters, etc. I reinstalled everything on a new instance, and the configuration worked (screenshot 1). However, an error appears in the application messages, and I'm not sure if I should worry about it (screenshot 2 and screenshot 3). There's a similar error on the PSO side (screenshot 4). Do you know where the problem might be?

regards

Daniel

 


Hi ​@Daniel,

glad you figured it out. What happens when you are loading the PSO Workbench? Does it redirect correctly to the IFSCLD Login Screen? Are you still seeing the above warnings (401 unauthorized and SSL error)?

Best regards
Roman


Hi, Is this what you mean? (screenshot 1). If so, clicking on it will open PSO Workbench as usual (screenshot 2)

 


It depends if your user is having the PSO permission set assigned and if you have enabled user sync. If yes, then it should log you in directly. When browsing to the PSO Workbench URL (e.g. in a new incognito window) you should get the IFSCLD Login Screen instead PSO Workbench User/Password Login Screen.

Best regards
Roman


Hi, I've attached a description of the scenario I used. Would you be kind enough to take a look at it?

regards

Daniel


Hi Daniel,

you do not need to create a user in IFS Cloud for usage in the connection configuration. You should use a PSO only user for that purpose.

Further, it seems there is still some issue either with the IAM Clients and/or the setup of the connection. As it’s getting a little bit out-of-hand here, I think you should reach out to your Partner Manager and request support by an IFS Consultant. I’m happy to help further, when there is an official request in place. Thanks for your understanding!

Best regards
Roman


Hi Daniel,

It looks like you have configured to use a certificate thumbprint (I see that in the “Open ID Authority Thumbprint” field in the assistant).

Certificate thumbprints are usually only needed if you use a non-trusted certificate, and the format is typically SHA-1 or SHA-256 coded, not the URL itself like you have.

If you use a trusted certificate then you don’t need to specify a certificate thumbprint. Make sure the “OpenIdAuthorityThumbprint” parameter is cleared out in PSO then.

There is a section on Certificate Thumbprints in the PSO Administration Guide.

Best regards

Claes


Hi Daniel,

It looks like you have configured to use a certificate thumbprint (I see that in the “Open ID Authority Thumbprint” field in the assistant).

Certificate thumbprints are usually only needed if you use a non-trusted certificate, and the format is typically SHA-1 or SHA-256 coded, not the URL itself like you have.

If you use a trusted certificate then you don’t need to specify a certificate thumbprint. Make sure the “OpenIdAuthorityThumbprint” parameter is cleared out in PSO then.

There is a section on Certificate Thumbprints in the PSO Administration Guide.

Best regards

Claes

Hi, It was it!! thanks you very much!!! 


Reply