For the Mgmt. Portal side you can follow through @Yuri Marx's example (though it uses Google and not Keycloak but the principal is similar, you will need a ZAUTHENTICATE, you will find a sample there).

Re your question about accessing the Access Token, you can include in your ZAUTHENTICATE something like this:

 set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(applicationName,sessionId,,.accessToken,,,.error)
 if isAuthorized {
    set sc=##class(%SYS.OAuth2.AccessToken).GetIntrospection(applicationName,accessToken,.jsonObject)
    ...
 }    
 // then you can access the jsonObject for getting info, e.g. (and this is from a KeyCloak example):
 set Username="OAuth2_"_jsonObject.username
 // or:
 set iterator=jsonObject."realm_access".roles.%GetIterator()
 while iterator.%GetNext(.key,.val) { 
    ...
 }

For the FHIR API you can look at @Luis Angel Pérez Ramos's example (though it uses auth0, but again it should be similar).
In this case you don't have to worry about ZAUTHENTICATE because the FHIR Server infrastructure has you covered.

By the way, in v2024.3 which was just released, there's a new OAuth FHIR Client QuickStart you can use to set this up in an easier manner.

For other REST services this would depend on their nature and whether there is user interaction which allows for example the actions described in the two samples mentioned above.

Note, my colleague @Ariel Glikman and myself are in the midst of a project that includes interacting with KeyCloak, and possibly once it's complete we can share some insights, but this will take some time, so I wouldn't hold my breath waiting for this.

Another note, I believe that down the line (perhaps even with v2025.1) we will have more seamless out-of-the-box integration with these kinds of OAuth authentication flows, which will require less background work as you need to implement today with ZUATHENTICATE etc. Stay tuned...

I believe you need to use PasswordHash, see for example from Docs:

[Actions]

CreateUser:Name=SQLAdmin,
  PasswordHash="cec6638a357e7586fddfb15c0e7dd5719a1964e774cd37466fb0c49c05,
  323cb89148c887166dd2be61c107710539af2c01b43f07dccc8d030ac2c1a8cf7c5ace4a00d57e3780f,10000,SHA512",
  Roles="%SQL,%DB_USER"

Re PasswordHash see more details in the related Docs. For example:

$ docker run --rm -it containers.intersystems.com/intersystems/passwordhash:1.1 -algorithm SHA512 -workfactor 10000
Enter password:
Enter password again:
PasswordHash=0fad6b1a565e04efb5fe9259da8457456883e0a3a42c1a34acec49cbbc1fb8c4c40f1846559ce180c103898db836,dd0874dc346d23679ed1b49dd9f48baae82b9062,10000,SHA512

I think you mean something like this:

https://docs.intersystems.com/iris20241/csp/docbook/DocBook.UI.Page.cls?...

For the machine you got the <WIDE CHAR> error for - did you install 8bit or Unicode?

Your $ZV without the 'U' after the build number, suggests 8bit. I would recommend you install Unicode (8bit support is there more for customers who have legacy 8bit databases).

For the machine you do see the web applications, but can't browse to the page - 

Did you enable the Web Applications?

(https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...)

Are you getting an error when you browse there? (you can check the Browser Debugger just in case)

Might it be an authentication/authorization issue? (you can check the IRIS Audit, making sure you have Login Failure and/or Protect events enabled)

Thank you, so this is clearer, and it is happening much earlier than I was thinking. You are not trying to connect via xDBC to your FHIR SQL Builder projected tables, but rather just trying to create the first Analysis step.

This error "shouldn't happen", and I recommend you turn to our Cloud Support.

What you could attempt doing before, is opening the browser debugger and see (perhaps under Network and the related HTTP requests you see) if you see some "interesting" error that could shed some light on what is happening.