今回は、SOA環境でのセキュリティー確保に関してID情報の伝播(プリンシパル・プロパゲーション)を取り上げます。
SOA環境でのセキュリティーを確保するための技術動向、および、SAP/IBMのSOA基盤が混在した環境でのセキュリティー技術の適用例をこれまでの連載でご紹介した業務アプリケーションのシナリオを通してご紹介します。
SOA環境でのセキュリティー
SOA環境は、本連載第1回で触れたように、複数の技術レイヤ(ポップアップ別ウィンドウ)(ユーザー・インターフェース層、プロセス制御層、バックエンドシステム層など)によって構成されます。これらの各レイヤにおいて、セキュリティー検討要素があります。
図1.セキュリティー検討要素
拡大図
セキュリティー検討要素
セキュリティー検討要素は、一般的に、図1に示すように大きく3つの領域に分けて考えることができます。アプリケーション・セキュリティー、システム・セキュリティー、ネットワーク・セキュリティーです。
SOA環境で検討すべき要素は、これらの一般的な検討要素と同じと考えることができます。複数のシステムを跨って処理が実行されるという特性上、特にSOA環境ではアプリケーション・セキュリティーに重点を置いて検討する必要があります。
アプリケーション・セキュリティーには、識別(ユーザーID)、認証、権限、などが挙げられます。
図2.セキュリティー検討要素
拡大図
SOA環境でのセキュリティー考慮ポイント
SOA環境では、図2に示すように複数の技術レイヤを跨って処理が実行されます。具体的には、システム機能はサービスと言う形で疎結合され、業務処理はユーザーが直接触れるフロントエンド・アプリケーションからプロセス制御層などの各レイヤを通して最終的にはバックエンドシステム上のシステム機能へと繋がります。
SOA環境は、上記のような特性を持つため、従来のIT基盤ではあまり意識することがなかったシステム処理を行ったユーザーのID情報をいかにしてシステム間で伝播していくのかを考慮する必要があります。
このように複数のシステムを跨ってID情報を伝播することをプリンシパル・プロパゲーションと呼びます。
SOA環境でID情報伝播を実現する技術
SOA環境でID情報を伝播するための方法として、シングルサインオンとプリンシパル・プロパゲーションが存在します。
図3. シングルサインオンとは
拡大図
図4. プリンシパル・
プロパゲーションとは
拡大図
シングルサインオン
シングルサインオンとは、複数システムの認証処理を1度のログイン処理で実行するユーザーを認証する事を指します。シングルサインオンの例としては、図3のようにユーザーが個別のシステムを利用する度にIDとパスワードを入力して認証を行う必要があったものをポータルに一度ログインしてしまえば、個別のアプリケーションへのログイン操作が不要になるということを例として挙げることができます。
プリンシパル・プロパゲーション
プリンシパル・プロパゲーションは、SOA環境でのサービスの呼び出しがSOAレイヤを跨って実行される場合に、処理実行ユーザーのID情報が後続のシステムに伝播されることを指します。
図4では、ポータル層で実行されたユーザーの処理は、プロセス制御層、ESB層の2つのレイヤを通して、最終的なバックエンド層のERPに到達する様子を示しています。
ユーザーの処理はそれぞれの層ではサービス呼び出しの形で行われますが、それらのサービス呼出し時に処理を実行したユーザーのID情報が伝播される必要があります。
続いて、ID情報の伝播を実現するためのセキュリティー技術についてご紹介します。
ID情報の伝播を実現するセキュリティー技術
ID情報の伝播を実現するセキュリティー技術には、トランスポートレベルでのセキュリティー技術、および、メッセージレベルでのセキュリティー技術の2つの技術が存在します。
図5. SAPLogonTicketの
サンプル 拡大図
図6. LTPAのサンプル
拡大図
図7. トランスポートレベルでの
ID情報伝播の課題 拡大図
- トランスポートレベルでのセキュリティー
トランスポートレベルのセキュリティー技術は、httpプロトコルのCookieを利用します。Webサービスリクエストを受け取ったコンポーネントは、Cookieの中に入っているID情報を取出し、そのIDを利用してリクエストされたサービスを実行することでID情報の伝播が行われます。
SAP社のSOA基盤製品であるSAP NetWeaverではSAPLogonTicketが用いられますが、IBM社のWebSphere®ではLightweight Third Party Authentication(LTPA)が用いられます。
ユーザーIDに関する情報は、Cookieの中に暗号化されて埋め込まれ、図5(SAPLogonTicket)、図6(LTPA)のような形で受け渡されます。
図7に示されるように相互運用性に課題もあります。
例えば、LTPAをSAP NetWeaverでは解釈できないため、ID情報の伝播はできません。
また、http Cookieは、元はWebサーバーとブラウザとの間でセッションを管理するためのPoint-to-Pointのやり取りを想定した仕組みのため、プロトコルの仕組み上はID情報も相手側に伝わった段階で失われてしまいます。
複数の異機種混在の環境をサービスという形で処理が実行されるSOA環境ではトランスポートレベルでのセキュリティー技術には課題があることがご理解いただけると思います。
図8. メッセージレベルの
ID情報の伝播 拡大図
図9. SAML Tokenのサンプル
拡大図
- メッセージレベルでのセキュリティー
メッセージレベルのセキュリティーは、Webサービス間でやり取りされるXMLメッセージの中にID情報を埋め込んでコンポーネント間で伝播する技術です。この技術は、標準化団体OASISによってWS-Security規格として標準化されています。
WS-Securityでは、SOAPヘッダーの中にID情報を埋め込むことで認証情報を伝播することができます。WS-Securityでは、セキュリティー・トークンの形でID情報を埋め込みます。セキュリティー・トークンの実装形式としては、x.509 token、LTPA token、SAML tokenなどがあります。
WS-Securityは実装形式までは規定していないため、埋め込まれるセキュリティー・トークンはベンダーごとに実装形式が異なる場合があります。異機種間を跨るという目的のため、セキュリティー・トークン形式としては、WS-Securityと同様にOASISにて標準として規定されているSAML TokenとしてID情報を埋め込む形式が一般的といえます。
図8、9は、SOAPメッセージにSAML Tokenが埋め込まれる様子を示しています。
WS-Securityによるメッセージレベルのセキュリティー技術は、SOAPメッセージの中にID情報が埋め込まれることで複数の製品に跨ってEnd-to-Endで伝播されるため、SOA環境でのID伝播技術として適しているといえます。
SOA環境でのセキュリティー技術の方向性
SOA環境でのセキュリティー技術として、トランスポートレベルのセキュリティー、および、メッセージレベルのセキュリティーの2つの技術によるID情報の伝播技術をご紹介しました。
ご紹介したセキュリティー技術とその特徴については、図10をご覧ください。
図10. SOA環境での
セキュリティー技術と方向性
拡大図
従来は、ID情報の伝播技術としては、SAPLogonTicketやLTPAなどのCookieを利用されてきました。今後、企業のITシステムがSOAに移行するに従って、異機種混在、および、複数レイヤを跨ったWebサービスの連携を考慮するとWS-Securityを利用したID情報の伝播を考慮する必要があります。
WS-Securityは、規格としては比較的新しい技術であるため、SOA基盤としての対応が進みつつある状況です。従って、ID情報の伝播のための技術手段としては、利用する基盤製品のセキュリティー技術対応度合いを留意し、システムのランドスケープにあわせて最適な基盤技術の採用を検討する必要があります。
基盤製品では、トランスポートレベルのセキュリティー、および、メッセージレベルのセキュリティーの両方に対応し、他のSOAレイヤに対する接続性を確保しつつあります。
図11. SAP NetWeaver Composition
EnvironmentでのID伝播設定の例
拡大図
図11は、両方のセキュリティー技術に対応しているSAP NetWeaver Composition EnvironmentにおけるID伝播設定の例です。
SAP NetWeaver Composition Environmentでは、Webサービスのプロバイダー/リクエスター共にトランスポートレベルのセキュリティー、および、メッセージレベルのセキュリティーに対応していることがご覧いただけるかと思います。
セキュリティー技術の適用例
当節ではID情報を伝播するためのセキュリティー技術を実環境への適用事例について、当連載でご覧いただいたアプリケーションシナリオを例にしてご紹介します。
ID情報の伝播のシナリオとして、これまでご紹介したシングルサインオン、および、プリンシパル・プロパゲーションの例をご紹介します。
ポータル環境からのシングルサインオン
ポータル環境からのシングルサインオンのシナリオとして、SAP NetWeaver PortalとWebSphere Portalを利用した2つのシナリオをご紹介します。
図12. SAP NetWeaver Portalから
FormWaveへのシングル
サインオン 拡大図
図13. WebSphere上で
SAPLogonTicketを受け取る
設定例 拡大図
- SAP NetWeaver Portalからバックエンドシステムへのシングル・サインオン
本連載第3回のシナリオでは、FormWaveの稼働するWebSphere上でSAPLogonTicketを受け取る設定を行うことで、SAP NetWeaver PortalとFormWave間でのシングルサインオンを実現しています。
先に触れましたようにSAP NetWeaverとWebSphereではそれぞれ採用するCookieの仕様がSAPLogonTicketとLTPAという形で異なるため、製品のデフォルトの状態ではID情報の伝播を相互に行うことはできず、シングルサインオンはできません。
WebSphere上でTAI(Ticket Association Intercepter)という技術を利用し適切な設定を行うことでWebSphere上でのSAPlogonTicketの受け取りが可能となります。図13はWebSphere上でのTAIの設定イメージを示しています。
FormWaveは、WebSphere上でするJava™アプリケーションであるため、SAP NetWeaver Portalで発行されたID情報が埋め込まれているSAPLogonTicketをWebSphere側で認識させることで、SAP NetWeaver PortalからFormWaveへのシングルサインオンが可能となります。
このように、異なる基盤製品を跨る連携であっても適切な技術を採用することでID情報を伝播することが可能となります。
図14. WebSphere Portalから
Notes、Sametimeへの
シングルサインオン 拡大図
図.15 Lotus Dominoでの
LTPA Token受け取り設定
の例 拡大図
- WebSphere Portalからバックエンドシステムへのシングル・サインオン
本連載の第6、7回「ポータルによるフロントエンドでのアプリケーション統合」では、ユーザーはWebSphere Portalにログインし、コラボレーションツールであるLotus Notes®やLotus® Sametimeを利用しています。
図14は、WebSphere Portal上にLotus Notes、および、Lotus Sametimeのポートレットを配置している画面例です。
WebSphere Portalにログインしたユーザーは、再度ログインすることなく、NotesメールやSametimeを利用して他のユーザーとのコミュニケーションを行うことができています。
Lotus Notes、および、Lotus Sametimeは、Lotus Domino®上でするアプリケーションであるため、WebSphere Portalで発行されるLTPA TokenをLotus Domino側で認識させる必要があります。
図15は、Lotus Domino上でLTPA Tokenを受け取るための設定例です。
プロセス制御層でのプリンシパル・プロパゲーション
プロセス制御基盤でのプリンシパル・プロパゲーションのシナリオとして、FormWave、SAP NetWeaver PI、WebSphere ESBの3つのシナリオをご紹介します。
図16.プロセス制御基盤
FormWave)による
ID伝播設定の例 拡大図
- プロセス制御基盤(FormWave)によるプリンシパル・プロパゲーション
FormWaveは、SOAレイヤにおいて人間系プロセス制御層に位置づけられます。
本連載第3回「申請・承認ワークフローと内部統制」のシナリオでは、承認者が購買依頼の申請を承認した段階で、FormWaveからSAP NetWeaver PIを経由しバックエンドシステムであるSAP ERPに購買依頼伝票を登録しています。
SAP ERPに購買依頼伝票を登録する際のユーザーとしてFormWave伝票の登録ユーザーの情報を伝播する必要があります。
図16は、FormWave上で処理ユーザーの情報を伝播する際の設定例を示しています。
FormWaveのデザインツール上で購買依頼伝票を登録するノードのプロパティを設定することで、処理実行ユーザーのID情報を他のSOA基盤に対して伝播することができます。
図17. プロセス制御基盤
(SAP NetWeaver PI)による
ID伝播設定の例 拡大図
- プロセス制御基盤(SAP NetWeaver PI)によるプリンシパル・プロパゲーション
SAP NetWeaver PIは、SOAレイヤにおいてESB層に位置づけられます。
本連載第3回「申請・承認ワークフローと内部統制」のシナリオでは、FormWaveからSAP NetWeaver PIを経由しバックエンドシステムであるSAP ERPに購買依頼伝票を登録しています。
図16にありますように、FormWaveから渡された処理実行ユーザーのID情報をバックエンドのSAP ERPに伝播する必要があります。
図17は、SAP NetWeaver PIでID情報の伝播設定をしている例です。
SAP NetWeaver PIへの接続相手先に対する接続属性の設定でプリンシパル・プロパゲーションの設定を有効化することでPIからSAP ERPのEnterprise Service呼出し時にID情報を伝播することができます。
図18. プロセス制御基盤
(WebSphere ESB)による
ID伝播設定の例 拡大図
- プロセス制御基盤(WebSphere ESB)によるプリンシパル・プロパゲーション
WebSphere ESBは、SOAレイヤにおいてESB層に位置づけられます。
WebSphere ESBは、単体ではLTPA Tokenを用いてID情報の伝播を行うことができますが、ID連携基盤製品と組み合わせることで、SAML TokenやRACFを使用したメインフレームとのID連携を行うことが可能です。
ここでは、ID連携基盤製品としてTivoli® Federated Identity ManagerとWebSphere ESBを利用してID情報の伝播がどのように実現可能かをご紹介します。
図18は、開発ツールであるWebSphere Integration Developer上でWebSphere ESBのメディエーション・モジュールを開発している画面例です。
Identity Mediation Primitiveと呼ばれるメディエーション部品を定義画面上にドラッグ&ドロップしパラメータ設定を行うことで、LTPA TokenからSAML Tokenへトークン形式を変換してSAP ERPのEnterprise Serviceを呼出しています。
このようにSOA基盤製品とID連携基盤製品を組み合わせて利用することで、比較的新しい技術といえるWS-Securityに対応できていない既存のバックエンドシステムをSOA環境に無理なく統合することも可能です。特に、既存システムとして古いバージョンのERPパッケージを利用している場合、あるいは、システムの改修に費用が必要となるメインフレームをSOA環境で利用し続ける場合には、有効なソリューションといえます。
SOA環境でのセキュリティー・アーキテクチャー
当節では、これまでご紹介したID情報の伝播技術を元にSOA環境でセキュリティーを確保するためのアーキテクチャーを整理いたします。
図19は、エンドユーザーが直接実行するフロントエンドPCから最終的に業務データが保管されるバックエンドシステムまでのEnd-to-EndのSOA環境のアーキテクチャーを示しています。
SOA環境でのID情報の伝播を行う場合、ユーザーの入り口であるポータルから個々のアプリケーションはシングルサインオンにてID情報を伝播します。
アプリケーションからプロセス制御層を通してバックエンドシステムまではプリンシパル・プロパゲーションの機能を利用してID情報を伝播します。
ID情報の伝播の技術手段としては、メッセージレベルのセキュリティー技術であるWS-Security標準に準拠したSAML TokenにてID情報を受け渡すことを検討します。基盤製品がWS-Securityに未対応であれば、トランスポートレベルでのセキュリティー技術であるCookie(SAPLogonTicketやLTPA)にてID情報の伝播を検討します。また、実際の企業システムにてメインフレームなどを利用している場合や多様なアプリケーションシステムを利用されていて採用するセキュリティー技術を統一することが困難な場合があります。
図19. SOA環境での
セキュリティー実現イメージ
拡大図
このような場合、SOA基盤を補完する製品を利用することもできます。
ここでは、簡単にこれらSOA基盤をセキュリティー面で補完する製品についてご紹介します。
図19には、3つのセキュリティー基盤があります。
セキュリティー基盤(1)の統合認証基盤では、エンドユーザーから個々のアプリケーションまでのシングルサインオンをサポートします。統合認証基盤では、広く利用されているさまざまな認証技術に対応することで、多様なベンダー製品へのシングルサインオンが可能です。ポータルシステムが個別アプリケーションへのシングルサインオンに対応できない場合でも統合認証基盤が個別アプリケーションへID情報を受け渡すことが可能となっています。
セキュリティー基盤(2)のID連携基盤では、ID情報を伝播する際のトークン形式としてさまざま種類に対応しています。前節でご紹介したように、LTPA TokenからSAP LogonTicket、SAML TokenやRACFなどWS-Securityに対応していない既存のバックエンドシステムもSOA環境に組み入れることが可能です。
セキュリティー基盤(3)のID配信基盤では、多数のユーザーIDの情報を一元管理し、SOA基盤に対して配信する機能を持ちます。SOA化した企業のシステム環境では、点在した各システム間で整合性の取れた状態でシステムを利用するユーザーIDやパスワードの情報を管理するのは運用上非常に負荷がかかります。ID配信基盤製品を利用することで、多数のシステムに対してユーザーIDやパスワードの情報を各システムで整合性を取れた状態で配信すると共にIDの改廃などの運用を円滑に行うことでシステム全体のセキュリティーを高めることにつながります。
関連情報
- ID統合基盤としては、Tivoli Access Manager製品などがあります。
- ID連携基盤としては、Tivoli Federated Identity Managerなどの製品があります。
- ID配信基盤としては、Tivoli Identity Managerなどの製品があります。
IBM, IBMロゴ, WebSphere,Tivoliは、International Business Machines Corporationの米国およびその他の国における商標。
JavaおよびすべてのJava関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標。