ソリューション

マクニカネットワークスが取り扱う製品で、皆様の課題を解決します

APIエコノミー時代の認証連携技術と
APIの保護の検証

APIエコノミー時代の認証連携技術とAPIの保護の検証

2016年8月末日にリリースされたPingFederateの新バージョン、PingFederate8.2でOpenID ConnectのRP(Relying Party)のサポート※1が発表されました。この機能を使ったユースケースを想定し、社内検証を実施してみました。
なお、本記事のテーマは「APIエコノミー時代の認証連携技術とAPIの保護」になりますが、本題に入る前に"APIエコノミー"という言葉について簡単に補足させて頂きます。

APIエコノミーとはAPIを積極的にサードパーティに公開したり、あるいはサードパーティのAPIを利用することで、新しいサービスを創出したり、新しい付加価値を提供するという経済活動や潮流を意味する言葉で、Fintech、IoT、ビッグデータの活用といったシーンでの利用が話題になっています。
従来のAPIではソフトウェアのAPI化が通常でありましたが、APIエコノミーではその企業のビジネスそのものをサービスとしてソフトウェア実装し、さらにオープンAPI化することが可能になります。例えば、ある地図アプリがあったとして、レストラン予約アプリとの連携によって、地図アプリを利用しながら地図上に掲載されているレストランを(レストラン予約アプリとして)予約するといったことが可能になります。APIエコノミーでは、ビジネスのアジリティ(俊敏性)を高めることはもちろん、オープンイノベーションの促進にも貢献する可能性があります。

今回の検証の概要とシナリオ

さて、今回のAPIエコノミーの検証ですが、サービスA(金融機関)がAPIを公開し、サービスB(資産管理サービス)から利用が行われ、ユーザに対して新たなサービスを提供するというケースを想定しています。

今回の検証の概要とシナリオ
  • サービスB(資産管理サービス)はサービス利用時にユーザ認証を行います。
    サービスB(資産管理サービス)側で自前のユーザ認証機能を実装することは可能ですが、利用ユーザの利便性を考慮しサービスA(金融機関)側の認証を使いたいと考えています。→ 認証連携技術(OpenID Connect)
  • サービスB(資産管理サービス)はサービスA(金融機関)側のリソース(ユーザの預金残高等)にアクセスをする必要があります。この時、セキュリティ上の理由により以下が必須要件となります。
  • サービスB(資産管理サービス)がサービスA(金融機関)のAPIへアクセスするにはユーザの承認が必要となり、APIアクセスに伴い、サービスB(資産管理サービス)に対してサービスA(金融機関)が管理するユーザのクレデンシャル情報(パスワード等)を共有してはならない。 → APIの保護(OAuth2.0)
今回の検証の概要とシナリオ

このシナリオに基づき、今回の検証の説明を行います。ユーザ認証およびAPIの提供元である金融機関をHIGU-BANKとします。HIGU-BANKと認証連携を行い、HIGU-BANKのAPIを利用する資産管理サービスをHIGU-ASSETとします。認証連携にはOpenID Connect、保護されたAPIに対するアクセス認可にはOAuth2.0を使います。

OpenID Provider/OAuth2.0 Authorization ServerはPingFederateとLDAPサーバを連携して実装してみました。今回のユースケースであれば、連携先は金融機関のポータル画面であったりする方がより現実的ですが、今回は簡易的にLDAPで検証しています。

今回の検証の概要とシナリオ

OpenID Connect Relying Party(RP)はPingFederateとApache Tomcatで構成しました。OpenID RPとして動作するPingFederateはHIGU-BANKのOpenID ProviderであるPingFederateから発行されるID TokenおよびAccess Tokenを受信し、WebアプリケーションであるApache Tomcat側にユーザの属性情報およびOAuth2.0 Access Tokenを渡しています。PingFederateとApache Tomcat間の連携はAgentless Integration Kit※2を使用しました。

今回の検証の概要とシナリオ

OAUTH2.0 Resource Serverとして、PythonのREST APIフレームワークであるEVE※3を使ってAPIサーバを構築し、PingAccess※4で保護しています。PingAccessはOAuth2.0 Resource Serverとして振る舞い、バックエンドのAPIサーバに対するアクセス制御を行っています。

今回の検証の概要とシナリオ

実際の設定内容(抜粋)

それでは実際の設定を抜粋してご紹介します。
HIGU-BANK.COMのOpenID Provider/OAuth2.0 Authorization Serverの設定は下図の通りで、OAUTH2.0 AS RoleとOpenID Connectを有効にします

実際の設定内容(抜粋)

下図はスコープの設定です。OpenID Connectログインに必要となるopenid以外に、profile、email、それとHIGU-BANKの預金残高を示すdeposit-balanceというスコープを定義しました。

実際の設定内容(抜粋)

下図はOpenID Connect Replying PartyとなるRP.HIGU-ASSET.COMの登録です。Grant typeとしてAuthorization codeを選択しています。実際のシーンではRefresh Tokenも有効にすることになるかもしれません。

実際の設定内容(抜粋)

OAuth2.0 Resource ServerとなるAPI.HIGU-BANK.COMも登録しておきます。ここで着目したいのはGrant typeにAccess Token Validationを設定している点です。

実際の設定内容(抜粋)

RP.HIGU-ASSET.COMは取得したOAuth2.0 Access Tokenを使って、PingAccessが保護しているAPIサーバ(API.HIGU-BANK.COM)にアクセスを行います。
PingAccessはRP.HIGU-ASSET.COMから渡されるAccess Tokenの検証を行い、APIサーバへのアクセス制御を行います。この設定はPingAccessが受け取ったAccess Tokenの検証を受け入れるための設定になります。

なお、RFC6749※5で規定されている「The OAuth 2.0 Authorization Framework」では、標準となるAccess Tokenの検証方法については言及されていません。つまり個々の実装にゆだねるということになりますが、ここではPingFederate側で拡張実装しているAccess Tokenの検証機能を使っています。※6

OpenID Provider側の設定をもう一つご紹介します。ID Tokenに格納されるsub属性、およびUserinfo Endpointから取得する追加属性に格納する情報についての設定です。

実際の設定内容(抜粋)

以上がAUTH.HIGU-BANK.COM側の設定のご紹介となります。

続いてRelying PartyであるRP.HIGU-ASSET.COM側の設定をご紹介します。
下図の通り、ProtocolとしてOpenID Connectが利用可能になっています

実際の設定内容(抜粋)

また、OpenID Providerの指定と、OpenID Provider側で登録したRelying Partyについての情報を登録します。

実際の設定内容(抜粋)

下図のとおり、Agentless Integration KitでOpenID Connectで取得した属性情報をApache Tomcatに受け渡しする設定になります。ユーザの属性に加えて、Resource Serverにアクセスする際のAccess Tokenを受け渡しするようにします。

実際の設定内容(抜粋)

下図はOpenID Providerに関する情報です。OpenID ProviderのURLを入力すると自動的にメタデータにアクセスし、設定が補完されます。
以上がRP.HIGU-ASSET.COMに関する設定のご紹介となります。

実際の設定内容(抜粋)

続いてAPI.HIGU-BANK.COMである、PingAccess側の設定をご紹介します。PingAccessがOAUTH2.0 Resource Serverとして振る舞うために、APIアクセス時に受信するOAuth2.0 Access Tokenの検証を行います。
検証は※6にあるように、Access Tokenを発行したOAuth2.0 Authorization Serverであるauth.higu-bank.comに対して行われますので、下図のとおりその指定をしておきます。

実際の設定内容(抜粋)

下図はSiteの設定です。SiteとはPingAccessが保護する対象となるWebアプリケーションやAPIであり、今回のケースではEVEで構築したAPIサーバになります。

実際の設定内容(抜粋)

下図はApplicationの設定です。今回、PingAccessはREST APIサーバを保護するリバースプロキシとして動作しています。

実際の設定内容(抜粋)

図内のVirtual Hostはリバースプロキシとして受けつけるPingAccess側の仮想ホスト名になります。Application TypeはWebかAPIから選択します。今回の保護対象はAPIとなりますのでAPIを選択しています。Destionationは実際に保護する対象ですので、先ほどsiteとして登録したEVE REST APIを指定しておきます。

下図はPolicyにおける保護対象のAPIに対する条件の設定です。ここではOAuthのscopeに"deposit-balance"(預金残高データへのアクセス)が指定されていればアクセスを許可するという設定をしています。

実際の設定内容(抜粋)

以上がPingAccessの設定のご紹介となります。

テスト結果

それではさっそく動作を見てみましょう。
まず、初めに資産管理サービスであるRP.HIGU-ASSET.COMにアクセスしますと、金融機関の認証サービスであるAUTH.HIGU-BANK.COMにリダイレクトされます。実際のシーンでは、資産管理サービスの認証ページに"HIGU-BANKで認証する"というボタンがあり、そこをクリックするというのが一般的になります。

テスト結果

下図のとおり、HIGU-BANKの認証画面でユーザ名とパスワードを入力します。今回の検証では連携しているLDAPサーバ内に格納しているユーザ名とパスワードを入力します。

テスト結果

正しいユーザ名とパスワードを入力すると、ユーザに対してOpenID Connectでのログインに加えて、下図のとおりAPIリソースに対して許可を求める画面が表示されます。事前にRP.HIGU-BANK.COM側のPingFederateで設定していたスコープが表示されます。

テスト結果

Allowをクリックすると、OpenID Connectによる認証連携が行われ、最終的にsub等のユーザ属性に加えて、OAuth2.0 Access Tokenの情報がWebアプリケーションであるApache Tomcatに渡されます。実際のシーンでは、ここで資産管理サービスに対して下図のとおり認証が完了しています。

テスト結果

続いて、受信したAccess Tokenを使ってAPIサーバに接続するテストを実施してみます。

APIのテストにはGoogle Chromeの拡張機能である"POSTMAN"※7を使用しました。Access Tokenは「RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage」※8に記載されている方法でAuthrorizaionヘッダの値として下図のとおり「Bearer アクセストークン」というフォーマットで送信します。

テスト結果

送信されたAPIリソースを保護するPing Accessに対して送信されたAccess Tokenは、※6に記載されている方法で検証されます。Access Tokenの有効性が確認されると、下図のようにAPIへのアクセスが許可されます。

テスト結果

ちなみにAccess Tokenを無効なものに書き換えてアクセスすると下図のような応答結果が返り、APIへのアクセスが拒否されます。

テスト結果

更にscopeとして下図のとおり"deposit-balance"のチェックを外してAccess Tokenを取得してみます。

テスト結果

今回、PingAccessではOAuthのscopeとして"deposit-balance"が指定されている場合に限ってAPIへのアクセスを許可していましたので、アクセスは拒否され下図のような応答結果が返ることが確認できました。

テスト結果

総評

いかがでしたでしょうか?専門用語が多くやや難解な箇所もあったかと思いますが、おおよそのイメージをつかんでいただければ幸いです。

2014年に標準化されたOpenID ConnectはOAuth2.0を拡張して作られました。そのため、今回のようにAPIの保護というシナリオと共に使われるシーンにおいて抜群の相性が発揮されます。
認証連携プロトコルというと、エンタープライズの世界ではほぼデファクトといわれるSAML2.0を思い浮かべる方が多数だと思いますが、今回のようなケースをSAML2.0で実装しようとするとかなり大変です。
SAML2.0と比較して実装が楽、軽量、モバイルアプリとの相性の良さが謳われ、徐々に採用が進んできているOpenID Connectですが、今回のようにOpenID Connectが適した具体的なユースケースが増えてくると更に採用される機会が増えていくかもしれません。OpenID Connectの今後について、今まで以上に注目していければと思います。

著者:マクニカネットワークス株式会社 技術統括部プロダクト第6技術部 部長 樋口 敏幸

※1
https://documentation.pingidentity.com/pingfederate/pf82/index.shtml#releaseNotes/pf_c_82.html関連してOpenID ConnectのOP(OpenID Provider)機能はPingFederate7.0、OAuth2.0のAS(Authorization Server)機能はPingFederate6.5でサポートされています。
※2
https://documentation.pingidentity.com/display/AIK12/Implementing+SP+Functionality図ではPingFederateがSAMLアサーションを受信しているが、本検証ではOpenID ConnectのID TokenとOAuth2.0 Access Tokenを受信しています。
※3
http://python-eve.org/かなりお手軽にREST APIサーバを構築できました。
※4
OpenID ConnectやOAuth2.0といった標準プロトコルを使い、WebアプリケーションやAPIに対するアクセス制御を行うPing Identity社の次世代WAM(Web Access Management)製品。
※5
https://tools.ietf.org/html/rfc6749
※6
https://developer.pingidentity.com/en/resources/oauth-2-0-developers-guide.html#validate_tokenなお、PingFederate 8.2およびPingAccess4.1ではRFC7662 OAuth2 Token Introspectionをサポートしており、AS-RP間でのtoken検証は、今後そちらが広く使われていく見込みです。
RFC7662:https://tools.ietf.org/html/rfc7662https://developer.pingidentity.com/en/resources/oauth-2-0-developers-guide.html#validate_token
※7
https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?utm_source=chrome-app-launcher-info-dialog
※8
https://tools.ietf.org/html/rfc6750

いつか見た景色 from Staff's Albums