IGA 3.7.3 - FQDN of OSP has changed

Dear Forum,

in my lab environment I have installed IDM Applications and OSP on one Server and IG on an other server. 

The setup was working, quite well.

After a while I changed the IDM Applications and OSP to run behind an Apache proxy and changed the FQDN as well.

Access to IDM Applications through the new FQDN and an url like https://newserver is working as expected. 

Since IG was using the OSP on the IDM Application Server by the URL https://oldserver:8543 I know I have to change the IG configuration, but this ain't work

First, I started the configutil provided by the IG installation and changed the OSP server in the authorization configuration.

But after pressing save the configutil gets stuck - I waited for several minutes, but it did not terminate.

Checking the ism-configuration.properties on the IG server I found two parameters still referring to the old OSP URL https://oldserver:8543, and I changed those parameters manually to https://newserver - but with no success. Accessing the login page, the browser is offering only a blank page! Using the browser development tools I found, it still is trying to access https://oldserver:8543

Can anybody provide some ideas how to fix the IG setup without reinstalling the whole server!

Kind regards


  • In addition to configutil, you will want to run configupdate as well to config the URLs.   Note that in recent versions the file ism-config and the ism-global config aren't authoritative for those settings. The values in the database ism-config table are authoritative.  The config tools are modifying the database.   You may also like to run configutil in -console mode, and take a look at all the available properties.  You might find some URL's that are not exposed in the GUI there that you may need to set.

    ALSO, you might need to look at the name resolution on the box running OSP.  during startup it tries to evaluate its own hostname (/etc/hosts file perhaps) and it will provide endpoints on what it thinks its running as.   One way to check the health of OSP is to hit this URL: http(s)://server:prt/osp/a/idm/auth/app .   That will let you authenticate right to OSP, and it will bring you to a blank dashboard if OSP is functional.   

    Similarly, there is a URL HTTP(s)://server:prt/osp/a/idm/auth/oauth2/.well-known/openid-configuration   that you should be able to hit that will show you the endpoint URLs that OSP is hosting for token service.  You will want to confirm these all look appropriate.

    I'd love to hear if you get OSP working behind a proxy - during use of the IG tool there is quite a bit of token traffic to OSP, so it may be more complicated that what I've mentioned here.


  • I agree with everything Jim said.  You can look at the DB itself, I find easier to find bad settings...  I forget the table name but it is very obvious.

    Also, the certificate uses for SSL must have a Subject Alternate Name for the new FQDN.  You can turn on a Java opt to override that, but best to re-mint the certificate.

    Also if DNS returns two names for the IP during resolution, there is something about it prefers the longer or shorter name.  There is a setting to tell it the preferred name in OSP.

  • It is:idm_global_config

    Also, that's a great point about the certificates.   You will need to ensure not only so the subject and subject alt names match up correctly, but that they (the tls certs for OSP) are trusted on the side where IG is hosted for the OSP certs.  Similarly, the IG server's tls cert will need to be trusted by OSP.   In previous versions I've added certs to the java truststore on the system as well as the osp truststore, and the tomcat/conf truststores, and that has worked, although I can't explain the details of which one is used when.


  • Verified Answer

    I highly recommend launching configutil in console mode and then issue: es
    This will dump all of the Global (database) and Local properties (ism-configuration.properties).

    This is one (1) of the first things that I request via Support when working on "configuration" kinds of issues.

    Steven Williams
    Principal Enterprise Architect
    OpenText Cybersecurity

  • Oh, that is slick!   I usually craft a script with 'dc' in it, then pass that to configutil and redirect the output, but I like this much more!


Reply Children
No Data