新しい投稿

検索

質問
· 2026年1月5日

IRIS Delegated Authentication Not Triggering ZAUTHENTICATE with Kong API Gateway

We are implementing delegated auth between Kong Gateway and IRIS. Kong is correctly configured to forward JWT authenticated requests with consumer headers (X-Consumer-Username, etc.) to IRIS, but the ZAUTHENTICATE routine (deployed in the %SYS namespace) never executes, leaving ZW ^ZAUTHLOG empty despite successful header delivery.

401 errors response:
...
* Request completely sent off
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Date: Fri, 02 Jan 2026 16:03:48 GMT
< CACHE-CONTROL: no-cache
< EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT
< PRAGMA: no-cache
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Server: kong/3.11.0.3-enterprise-edition
< X-Kong-Upstream-Latency: 17
< X-Kong-Proxy-Latency: 1
< Via: 1.1 kong/3.11.0.3-enterprise-edition
< X-Kong-Request-Id: d1e1be43c3b00050672d105fb285c519

* Connection #0 to host kong.dev.azure.asmodee.com:443 left intact
 

ZAUTHENTICATE code:

ZAUTHENTICATE(ServiceName, Namespace, Username, Password, Credentials, Properties) PUBLIC {
    SET idx = $INCREMENT(^ZAUTHLOG)
    SET ^ZAUTHLOG(idx,"$H") = $H
    SET ^ZAUTHLOG(idx,"Service") = ServiceName
    SET ^ZAUTHLOG(idx,"Namespace") = Namespace
    SET kongConsumer = ""
    IF $ISOBJECT(%request) {
        SET kongConsumer = $GET(%request.CgiEnvs("HTTP_X_CONSUMER_USERNAME"))
    }
    SET ^ZAUTHLOG(idx,"Kong_Consumer_From_Header") = kongConsumer
    SET ^ZAUTHLOG(idx,"ServiceName_Received") = ServiceName
    IF kongConsumer="" {
        SET ^ZAUTHLOG(idx,"Result") = "REJECTED_NO_KONG_HEADER"
        QUIT $SYSTEM.Status.Error($$$InvalidUsernameOrPassword)
    }
    SET Username = "jarvis_proxy"
    SET ^ZAUTHLOG(idx,"IRIS_Username") = Username
    SET ^ZAUTHLOG(idx,"Result") = "AUTHENTICATED"
    SET Properties("Username") = Username
    QUIT $SYSTEM.Status.OK()
}
 

Troubleshooting Done:

  • AutheEnabled set to 8192 (Delegated, Bit 13 per Security.Applications documentation).
  • ZAUTHENTICATE routine compiled with Resource Required parameter.
  • Headers verified reaching IRIS (Web Gateway logs).
  • Kong request-transformer plugin is working correctly.
  • Manual testing shows routine executes, but delegated requests don't trigger it.
  • We also tested delegated authentication by calling IRIS directly (bypassing Kong) with pre-set headers; ZAUTHENTICATE still doesn't trigger. Unauthenticated and Password auth methods work well.



Does ZAUTHENTICATE require specific conditions to execute (session state, pre-auth check)? What am I missing ?
Thank you for any help !

5 Comments
ディスカッション (5)2
続けるにはログインするか新規登録を行ってください
記事
· 2026年1月5日 1m read

Note concernant le paramètre "Rester connecté" (StayConnected) pour les adaptateurs TCP

FAQ InterSystems

Les paramètres par défaut pour la connexion permanente et la taille du pool pour les hôtes professionnels utilisant l'adaptateur TCP sont les suivants :

StayConnected = -1(no timeout)
PoolSize = 1

Si un problème réseau entraîne la perte de connexion à un serveur d'entreprise, le système de production ne pourra pas le détecter et refusera toute nouvelle connexion. Dans ce cas, aucun événement n'est consigné dans le journal des événements. Si la valeur de StayConnected est définie sur sa valeur par défaut (-1), les connexions n'expireront pas et vous devrez redémarrer le serveur d'entreprise pour qu'il puisse accepter de nouvelles connexions. Nous recommandons de définir StayConnected sur une valeur supérieure ou égale à 0 afin d'éviter ce problème.

Par exemple, si vous le définissez sur 300 (secondes), un hôte d'entreprise TCP peut se déconnecter et se reconnecter automatiquement s'il ne reçoit aucun nouveau message pendant 300 secondes ou plus.

Pour les systèmes très sollicités, il est généralement conseillé de définir la valeur StayConnected à une valeur plus faible, par exemple 5 secondes.

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
ダイジェスト
· 2026年1月5日

Publications des développeurs d'InterSystems, semaine Décembre 29, 2025 - Janvier 04, 2026, Résumé

Articles
Annonces
#Communauté des développeurs officielle
Décembre 29, 2025 - Janvier 04, 2026Week at a GlanceInterSystems Developer Community
記事
· 2026年1月5日 3m read

Using Postman for testing the OAuth2.0 of the InterSystems FHIR repository - Part2

Hi, now I would like to continuous on the topic that we talk about previously

Using Postman for testing the OAuth2.0 of the InterSystems FHIR repository - Part1

 


Question 1: Where is my client_id and client_secret come form?

Short answer: Authentication Server.

 

If you don't have an Authentication Server, you may set up one as following

 

Provide the hostname (the host must support Https), at least 1 grand type (we choose client credential here), and SSL/TSL configuration

 

Input the scopes (here we input user/*.read and user/*.write, which is based on the scope support by the FHIR server (resource server)). Just in case if there is some scope we missed, check the Allow unsupported scope.

 

JWT setting choose RS256 (this is just an example, you may choose the one that fit your architecture)

 

Change the Generate token class to %OAuth2.Server.JWT. And update the namespace if needed. 

Save the setting

 


Question 2: How to check out client_id and client_secret come form Authentication Server?

Short answer:  Setup an OAuth2.0 Client (if you don't have) and created a client

 

Below are the steps for setting up an OAuth 2.0 Client.

 

Click Create Server Description

 

 

Input the Issuer end point and SSL/TLS configuration here

and click Discover and Save

 

 

You can find the related information in the OAuth2.0 Server configuration page 

 

 

After the Discover and Save, you may see something similar to below. We may need to take a look at the token endpoint, which we need it for checking out a token

 

 

After the configuration above, now, it's time for us to create a client call postman 😁

Click on the OAuth 2.0 Client button

 

 

Click on the Client Configurations

 

 

Click Create Client Configuration

 

 

Input the Application name and Client name, choose the Client type confidential, input the Hostname for the Client redirect URL, choose the Required grant types Client credentials

Click Dynamic Registration and Save

 

 

You may see something similar as following.

Now, it's time to check out our client_id and client_secret😁😁

Click on the Client Credential tab

 

 

You can copy you client_id and client_secret here 😉

 

 

 


Question 3: How to add my FHIR server as resource server and related to Authentication Server?

Short answer:  Setup an OAuth2.0 Client (if you don't have) and create a resource server. Then apply the resource server to the FHIR server setting 

 

 

To create a resource server

 

 

Click on the Client Configurations

 

 

Click Create Client Configuration

 

 

Input the Application name and Client name, choose the Client Type Resource Server

Click Dynamic Registration and Save

 

 

Now the Resource Server is setup, then we should apply it to the FHIR server

Go to Health

 

 

Then, FHIR Server Management

 

 

Then choose the FHIR server to Edit

 

 

In the FHIR Server Authorization Setting tab, choose the OAuth Client Name from the list and Save 

 

Yeah!! I think that all we need to setup our InterSystems FHIR server with OAuth feature😁

 

 


For testing with Postman, you may refer back to the pervious article 

Using Postman for testing the OAuth2.0 of the InterSystems FHIR repository - Part1

Thank you very much for reading!😆😀

3 Comments
ディスカッション (3)2
続けるにはログインするか新規登録を行ってください