Question
· Nov 27

How to set up OAuth2 delegated authentication using Keycloak as identity provider?

I want to integrate IRIS with Keycloak OAuth2 provider to use delegated authentication everywhere and to secure everything - sys*/Portal applications, REST services, FHIR server and so on. If an unathenticated user tries to access any IRIS URL - he or she should be redirected to Keycloak. After the user has successfully authenticated, i would like to access his requistes (username, email, roles, scopes) extracted from the JWT token, programmatically. What should be done to achieve that? I found this repo but it seems a bit tricky to implement a custom ZAUTHENTICATE function which has an access to HTTP context and manages HTTP redirections according to OAuth2 flow.

Product version: IRIS 2024.1
Discussion (1)3
Log in or sign up to continue

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...