新しい投稿

検索

質問
· 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
続けるにはログインするか新規登録を行ってください
記事
· 2026年1月5日 10m read

OAuth FHIR Client Quickstart(バージョン2025.1以降)のご紹介

開発者の皆さん、こんにちは!

バージョン2025.1以降のIRIS for Healthの機能に、「OAuth FHIR Client Quickstart」が追加され  FHIR サーバーを OAuth2.0リソースサーバ―として簡単に設定できるようになりました。

この記事では、OAuth2.0 認可サーバーとして Auth0(Okta社 https://auth0.com/jp)を利用し、IRISに用意するFHIRサーバーを OAuth2.0 リソースサーバ―として設定し、Webアプリケーション(例ではPostman)からFHIRリソースにアクセスするまでの流れをご紹介します。

 

ご紹介する「OAuth FHIR Client Quickstart」 では、指定した外部の OAuth2.0 認可サーバーと連携し、FHIRサーバーを保護するための OAuth2.0 リソースサーバ関連設定を、IRIS および OAuth2.0 認可サーバー側に自動作成します。

Webアプリケーションの代わりに使用するPostmanからは、OAuth2 Authorization Code Flow でアクセストークンを取得します(ID Token は利用しません)。

以降の記述の中では、OAuth2.0認可サーバーを「認可サーバー」、OAuth2.0リソースサーバ―を「リソースサーバ―」と略して記載していきます。

【目次】

1. 認可サーバ機能の準備

2. OAuth FHIR Client Quickstart

2-1. FHIRサーバーを作成または選択

2-2. 認可サーバーの種類を選択

2-3. OAuthサーバーを構成する

3. 認可サーバーでの追加の設定

3-1. リソースサーバ―を登録する

3-2. 登録されたクライアントに適切なスコープを設定する

3-3. OAuth2.0クライアント(Postman)の登録

3-4. ユーザーの登録

4. Postmanでの操作

4-1. アクセストークの取得

4-2. FHIRリソースにアクセス

 

1. 認可サーバ機能の準備

この記事では、Auth0 を利用しています。

Auth0 は OAuth 2.0(認可)および OpenID Connect(認証)に対応しており、この記事では FHIR API 向けのアクセストークンを発行する認可サーバとして利用します。

Auth0 は、この機能を SaaS として提供しており、テナント作成により利用可能になります。

Auth0 でアカウント登録(テナント作成)を行うと、テナント単位で OAuth 2.0 / OpenID Connect 認可サーバー機能を利用できるようになります。

ここで、IRIS for Health のOAuth FHIR Client Quickstart からテナントで用意したサービスに対してクライアントの登録ができるように、設定を変更します。

テナント名をクリックし、「設定」に移動し、「詳細設定」をクリックします。

画面の下の方にある「動的クライアント登録(DCR)」を有効に設定します。

 

 

次に、認可サーバーのエンドポイントを調べるため、デフォルトアプリケーションの設定を確認します。

画面左のアプリケーションを展開すると「Default App」があり「詳細設定」を参照すると各エンドポイントを参照できます。

 

エンドポイントに記載された https://dev-***.jp.auth0.com/ までが認可サーバーのエンドポイントとして必要になるので、メモしておきます。

 

2. OAuth FHIR Client Quickstart

OAuth FHIR Client Quickstart を開始する前に、ネームスペース・データベースの作成を行います。

管理ポータルでの手順は以下の通りです。

管理ポータル > Health を選択し、下図のように画面上部に「Installer Wizard」が表示されますのでクリックします。

Configure Foundation」ボタンをクリックし、作成したい環境名(ネームスペース・データベース名)を「Local Name」欄に記入し、Saveボタンをクリックします。

その後、追加した環境をアクティベートするため画面右端にある「Activate」をクリックし、子画面内の「Start」ボタンをクリックします。

子画面に「Activate Done」と表示されたら完了です。

 

2-1. FHIRサーバーを作成または選択

FHIR Server Management 画面に移動するため、画面上部のメニューから「FHIR」を選択します。

(または、管理ポータル > Health > 作成したネームスペース名 > FHIR Server Management

以下のように表示されます。例では、事前にFHIRサーバーを用意してみます。

「Add New Server」をクリックすると子画面が表示されます。作成したネームスペース(例ではTEST)を選択し、FHIRサーバー名を設定します(例では test)。

 

Create」ボタンをクリックしてFHIRサーバーの作成を開始します。この処理は機材にもよりますが数分かかりますので完了するまでしばらく待ちます。

待っている間は以下のような表示です。

作成が完了すると以下の表示になります。

 

画面左の下部にあるをクリックすると、メニューがアイコンから字に変わります。

OAuth FHIR Client Quickstart」をクリックすると、既存のFHIRサーバーを選択するか、作成するかのメニューが表示されるので、「Use an Existing FHIR Server」を選択し「Next」ボタンをクリックします。

 

既存のFHIRサーバーがあるネームスペース(例では、TEST)と URL(例では /csp/healthshare/test/fhir/r4)を指定して「Next」ボタンをクリックします。

 

2-2. 認可サーバーの種類を選択

次に、使用する認可サーバータイプの選択画面が開きます。外部の認可サーバー(Okta社のAuth0)か、IRIS内の認可サーバーか選択します。

IRIS を 認可サーバーとして使用する場合は、安全な通信を設定する必要があります

また、FHIR をサポートする認可サーバーとして IRIS を設定する必要があります。作成用のメソッドも提供されています。)

この記事では、外部の認可サーバー(Okta社のAuth0を使用して設定を進めていきます。 

 

2-3. 認可サーバーを構成する

Issuer Endpoint」に「1. 認可サーバ機能の準備」で確認したエンドポイントを指定し、Testボタンをクリックします。テストが完了すると「Next」ボタンが表示されるのでクリックします。

 

確認用画面が表示されます。「Confirm」をクリックします。

作成が完了すると「Done」ボタンが表示されるので、クリックします。

 

この手続きの中では、IRISにあるOAuth2.0サーバ/クライアント設定に、認可サーバーとして指定した外部の認可サーバー情報と、リソースサーバーとして動作するFHIRサーバーの情報をクライアントとして登録しています(「This client name is:」以降に記載の名称で登録されます)。

また、FHIRサーバーのアクセスにOAuth2 を使用するため、FHIRサーバーの「FHIR Server Authorization Settings 」に作成された「OAuth2.0 クライアント」の名称が設定されます。

 

確認手順は以下の通りです。

FHIR サーバーの編集メニューを図のように開きます(Editを選択しています)。

FHIR Server Authorization Settings 内の「OAuth Client Name」に設定されていることを確認できます。

ここで確認した OAuth Client Name は、管理ポータルの以下メニューにもリソースサーバ―として登録されています。(将来のバージョンで FHIR Server Management画面でも確認できます)

管理ポータルトップ > システム管理 > セキュリティ > OAuth 2.0 > クライアント > クライアント構成 

 

この名称は、Auth0にも OAuth2.0 クライアントとして登録されています(Auth0では、「アプリケーション」として登録されています)。

メモ:Auth0 では、OAuth2 のクライアントを「アプリケーション」、リソースサーバを「API」として管理します。

 

 

3. 認可サーバーでの追加の設定 

3-1. リソースサーバ―を登録する

次に、リソースサーバの設定を行うため、Auth0ではAPIを作成しスコープを定義します。

メモ:Auth0 では、OAuth2.0 クライアントを「アプリケーション」、リソースサーバを「API」として管理します。

Auth0 の画面でAPIメニューを選択し「APIの作成」をクリックします。

名前欄に任意の名称を設定します。

識別子(Audience)には、FHIR サーバーを一意に識別できる URI を指定します(本例では FHIR エンドポイント URL を使用しています)。

パーミッションメニューを利用して、FHIR のスコープを追加します(適切なものを指定してください)。

 

3-2. 登録されたクライアントに適切なスコープを設定する

登録されたOAuth2.0 クライアント(Auth0ではアプリケーション)の設定画面に戻り、APIタブを選択します。

作成したAPIが表示されるので選択し、「許可済」となるようにチェックし、メニューを展開します。

APIで設定したスコープが表示されるので、必要なものを選択し、画面下にある「更新する」ボタンをクリックして設定を完了させます。

この設定で、この認可サーバーがアクセスするリソースサーバ―(FHIRサーバー)のスコープが確定します。

 

以上でリソースサーバ―のための設定は完了です。

次は、WebアプリケーションでFHIRリソースにアクセスできるようにするため、OAuth2.0 クライアント(Webアプリケーション)を追加します。

 

3-3. OAuth2.0クライアント(Postman)の登録

再び、Auth0のアプリケーション画面を開き、Webアプリケーション用のOAuth2.0クライアントを作成します。

例では、名称にPostman、種類は「一般的なWebアプリケーション」を選択し作成しています。

 

設定を修正します。

アクセストークンを取得する流れで使用するコールバック用URLを登録し保存します。(例:https://oauth.pstmn.io/v1/callback

また、この画面に表示されているクライアントIDクライアントシークレットはPostmanからアクセストークンを取得する際使用する情報となりますのでメモします。

画面下の方にある「詳細設定」を確認すると、OAuth Authorization URLOAtush Token URLの情報を確認できます(後ほど入力する情報です)。

 


3-4. ユーザーの登録

次に、認可サーバーにユーザー情報を登録します。

この例では、簡単に設定するためユーザーに直接スコープを定義していますが、ロールにスコープを定義し適切なロールをユーザーへ付与する方法のほうがユーザー追加や変更に対応しやすい設定となります。

Auth0の管理画面で、ユーザー管理ユーザーメニューを選択し、「ユーザーを作成」ボタンをクリックし新規ユーザーを登録します。

 

登録後、「パーミッション」タブで事前に定義したAPI(例ではFHIRTestAPI:リソースサーバ―)を選択し、必要なスコープを適用します。

これでアクセスのために必要な設定は完了です。

次は、アプリケーションからFHIRリソースにアクセスします。

 

4. Postmanでの操作

WebアプリケーションとしてPostmanを利用してテストします。

 

4-1. アクセストークの取得

Postmanの「Authorization」タブに移動し、AuthType:「OAuth2.0」を選択します。アクセストークンを取得するために必要な情報を入力します。

(Grant type:Authorization Codeを指定します。残りは事前に確認した情報を設定します。Scopeが複数ある場合はスペースで区切ります。)

参照したいFHIRサーバーの情報を「Advanced」以下にある「Auth Request」を利用して設定します。

  • Key:audience
  • Value:FHIRサーバーのエンドポイント

 

設定が完了したらボタンをクリックします。

認可サーバーのログイン画面が以下のように表示されるので、認可サーバーに登録したユーザ名、パスワードを入力します。

 

Use Tokenボタンをクリックすると、以下のようにTokenがコピーされます。

 

4-2. FHIRリソースにアクセス

アクセストークンが入手出来たら、いよいよFHIRサーバーへのアクセスです。

(まだリソースを登録していないので、0件の結果が返ればアクセスできている状態です)

 

テストデータ登録後、正しくリソースがGETできています。

 

OAuth FHIR Client Quickstart」では、外部の OAuth 2.0 認可サーバー(Okta の Auth0 など)を認可サーバとして利用し、IRISのFHIRサーバーをリソースサーバとして OAuth 2.0 で保護する構成を以前のバージョンより簡単に設定できるようになりました!

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