IBM webMethods Hybrid Integration SaaSご紹介!(API管理編②)
投稿者：平間 博
こんにちは。
私たちIntegrationチームはシステム/アプリケーションを統合するソリューションエンジニアであり、API、メッセージ・データ、ファイルを使った様々なデータソースやアプリケーションの統合において、製品の選定から設計・構築、そして導入後のサポートを行っております。
このBlogでは、2025年6月に発表され、2026年10月9日に無事に日本リージョンも展開されたIBM製のiPaaS製品「IBM webMethod Hybrid Integration(IWHI) SaaS」の構成、現状における類似機能の扱い方、制限事項などを順次取り上げて紹介してまいります。
第三稿目は、「API Connect」で提供しているAPIを、クライアントに仕様変更を強いることなく、「webMethods API Gateway」に移行する方法を解説します。
「API Connect」でAPIを特定のユーザーに対して提供する場合、コンシューマー組織、アプリケーションを定義して、それらを関連付けした上でサブスクライブするとクレデンシャルデータ(クライアントID/シークレット)が生成され、ユーザーはクレデンシャルデータを添えAPIをコールします。
対して「webMethods API Gateway」でもクライアントID/シークレットを生成することはできますが、これらはOAuth運用を前提としているため、クライアントID/シークレットのみで運用することは想定されていません。
そこで、本稿では「API Connect」と同様の振る舞いとなるような実装をガイドしていきます。
- 「webMethods API Gateway」でクライアントID/シークレットを生成するため、アプリケーションを定義します。
- クライアントクレデンシャルデータを生成し、アプリケーションのIdentifiersとして登録したら、APIに組み込みます。
以上、「webMethods API Gateway」で「API Connect」と同じようにクライアントID/シークレットのみを使った認証方式の実装について説明しました。
「API Connect」を「webMethods API Gateway」に移行を検討する場合、、可能な範囲でクライアントアクセスを変更しないで済ますためには考えなければポイントがいくつかあります。
本稿で取り上げたクライアントID/シークレットを「webMethods API Gateway」で扱えるようにする手法も、その一つです。
次回は、認可トークンに独自クレームを追加する方法を「IBM webMethods Hybrid Integration SaaSご紹介!(統合編①)」にてお届けします。
