JP2013513161A - アプリケーションクラスをロードするシステムおよび方法 - Google Patents

Abstract

アプリケーションにおいて、クラスのバリアントは、アプリケーションのための異なるセキュリティパーミッションを生成して関連付けることができる。クラスがロードされると、例えばセキュリティトークンをデコードすることにより、アプリケーションのセキュリティパーミッションに関して、決定が行われる。クラスは、要求されたセキュリティレベルにマッチするクラスバリアントを格納するリポジトリから検索される。セキュリティパーミッションに適切な完全または縮小された機能性を有する検索されたクラスバリアントは、ロードされる。

Description

本開示は、セキュアアプリケーションに関し、より詳細には、ユーザのセキュリティパーミッション（security permissions）に基づきアプリケーションにクラスをロードすることに関する。

デバイスでアプリケーションを呼び出す場合、アプリケーション、またはユーザのセキュリティパーミッションに依存するアプリケーションの幾つかのケーパビリティ（capabilities）に対して権限のないアクセスを妨げる必要がある。既存のソリューションは、アプリケーションロジック内、または保護された（protected）ケーパビリティがアクセス可能であるかどうかを決定するセキュリティモジュール内の条件付きのロジックを用いる。しかし、パーミッションが不正確に設定された場合、偶然または悪意のどちらでも、それらのケーパビリティを実装するコードがアプリケーションに認識されれば、保護されたケーパビリティはアクセスされ得る。これは、分散型アプリケーションにおいて重大な問題になり得る。

求められていることは、セキュアアプリケーションを発展させる、または／および提供するための、改善されたシステムおよび方法である。

本開示の1つの態様において、アプリケーションにおけるクラスをロードする方法であって、クラスの要求を決定するステップと、セキュリティパーミッションを決定するステップと、前記セキュリティパーミッションに関連付けられた、要求されたクラスのクラスバリアントを検索するステップと、検索されたクラスバリアントをロードするステップとを含む方法が提供される。

本開示の1つの態様において、要求ハンドラと、少なくとも１つのクラスローダとを含むアプリケーションが提供される。前記要求ハンドラは、クラスに対する要求を処理し、前記アプリケーションのセキュリティパーミッションを決定するように構成され得る。前記クラスローダは、前記セキュリティパーミッションに依存してクラスバリアントをロードするように構成され得る。

本開示の１つの態様において、プロセッサによって実行するコンピュータ実行可能命令を含むコンピュータ読取可能媒体であって、実行されるときに、前記プロセッサに、セキュリティトークンをデコードさせ、前記セキュリティトークンからセキュリティパーミッションを決定させ、前記セキュリティパーミッションに関連付けられたクラスリポジトリを選択させ、選択されたクラスリポジトリからクラスをロードさせる媒体が提供される。

ここで、具体的な実施形態および以下の添付の図面が、単なる一例として、参照される。

アプリケーションのストラクチャを示す図である。 図１のアプリケーションにクラスをロードするプロセスを示す図である。 呼び出しを実行するプロセスを示す図である。 クラスインスタンスを取得するプロセスを示す図である。 アプリケーションを実行するプロセスおよびメモリを示す図である。 図５のプロセッサで実行できる命令セットを示す図である。 クラスリポジトリプロセッサによる通信におけるアプリケーションプロセッサを示す図である。

アプリケーションストラクチャ１０が、図１に示される。アプリケーション１０は、ロードされ、アプリケーションの機能を実行するように用いられるアプリケーションクラス１２を含む。アプリケーションクラスは、典型的には、要求ハンドラ１５内のクラスローダ１４を用いてロードされる。本開示の1つの実施形態では、アプリケーション１０は、セキュリティトークンとして符号化された一組のセキュリティパーミッションを有するように構成されることが可能である。アプリケーションが、セキュア機能を実行するとき、要求ハンドラ１５は、呼び出しをインターセプトする。要求ハンドラ１５は、呼び出し元にローカルであり、またはリモートプロセスにおいて存在する。本実施形態のクラスローダ１４は、セキュリティトークンにおいて符号化されたパーミッションに基づいたクラスの複数のバリアントをロードするように構成される。セキュリティトークンは、アプリケーションが特定の計算デバイスにインストールされるとき、ユーザがログイン操作を実行するとき、またはユーザのセキュリティ認証情報を確立する他の任意の手段で、生成される。分散型アプリケーションにおいて、セキュリティトークンは、セキュア（暗号化された）コネクションを通したリモート呼び出しなどの、リモート機能を実行するための確立された構造を用いてプロセス間を通過する。クラスローダ１４は、どのバリアントがロードするかを決定するために、セキュリティパーミッションを使用する。

クラスをロードするためのプロセスは、図２のフローチャート１００において示される。ステップ１０１において、ロードされるクラスに対する要求が、生成される。アプリケーションに対するセキュリティパーミッションは、評価される（ステップ１０２）。セキュリティパーミッションと関連付けられた要求されたクラスのクラスバリアントは、検索されて（ステップ１０３）、ロードされる（ステップ１０４）。

パーミッションの具体的なセットは、クラスの具体的なバリアントセットにマッピングされる。各セットは、クラスの異なるグループを含むことができる。しかし、アプリケーションによって直接アクセスされる各バリアントのクラスは、同じ名前および名前空間を有し、同じパブリックのＡＰＩを提供する。バリアントのクラスの各セットは、リポジトリＡ１７、リポジトリＢ１８等、別々のリポジトリに含まれる。クラスリポジトリは、ファイルシステムにローカルに配置され、またはセントラルリモートサーバ（central remote server）からネットワークを介して使用可能である。クラスローダ１４は、どのリポジトリが、セキュリティパーミッションを使用することからクラスをロードするかを決定する。アプリケーションが、セキュリティパーミッションに依存するクラスへのアクセスを必要とするとき、クラスローダは、そのアプリケーションのパーミッションに基づいて、適切なリポジトリからクラスのバリアントをロードする。これは、保護されたケーパビリティの偶然または悪意ある使用からシステムを保護する。何故なら、クラスの各バリアントは、正しい名前空間を有し、かつ正しいパブリックのＡＰＩを提供するので、クラスは、アプリケーション内にロードされ呼び出されるとき、適切に実行することになる。

クラスの1つのバリアントは、管理上のセキュリティパーミッションを有するユーザによりアクセスだけ可能な、フル（full）ケーパビリティを提供するように暗号化されることができる。このとき、同じクラスのもう1つのバリアントは、読み出し専用のセキュリティパーミッションを有するユーザによりアクセス可能な縮小した機能性を提供するように暗号化されることができる。例えば、1つのクラスバリアントは、すべてのユーザのアカウントの作成および削除をサポートする。別のクラスバリアントは、作成または削除ではなく、アカウント情報の更新をサポートする。第３のクラスバリアントは、カレントユーザのためのアカウント情報の表示のサポートだけをする。

図３では、アプリケーションにより、クラスの呼び出しを実行するためのプロセス２００が示される。ステップ２０１では、要求ハンドラ１５は、呼び出しを受信し、ステップ２０２において、呼び出しからセキュリティトークンをデコードする。セキュリティトークンが有効ならば（ステップ２０３）、クラスローダ１４は、セキュリティトークンにおいて示されるセキュリティパーミッションにマッチする適切なクラスリポジトリからクラスバリアントを検索する（ステップ２０４）。検索されたクラスは、呼び出しを実行するように使用される（ステップ２０５）。

クラスインスタントを検索するためのプロセスは、図４のフローチャート３００において示される。ステップ３０１において、クラスの要求は、要求されるセキュリティパーミッションに基づいて生成され、クラスの操作は実行される。ステップ３０２で決定されるようにクラスが予めロードされ、ステップ３０３で決定されるように使用可能なクラスのインスタンスがあれば、呼び出しは、規定通りに実行される３０５。クラスインスタンスが使用できずに予めロードされていたら、クラスインスタンスは、呼び出し３０５を実行する前に、ステップ３０４で作成することができる。クラスが予めロードされていなかった場合（３０２）、クラスをロードするように使用されるクラスローダは、ステップ３０６において決定される。各クラスリポジトリは、アプリケーション内に各クラスリポジトリのための別々のクラスローダを有するようにしてもいい。このことは、アプリケーションを適切にファイアウォールするのに役立ち、同じクラスの複数のバリアントが、同じアプリケーションのプロセス内でロードされるのを可能にする。クラスローダは、例えばセキュリティトークンから等、クラスの要求に指し示されるセキュリティパーミッションに基づいて、決定される。選択されたクラスローダが、使用可能であれば（３０７）、クラスは、ロードされる３０８。クラスが、ステップ３０９で決定されるようにうまくロードされると、クラスのインスタンスは、呼び出しが実行される３０５ことができるように、生成される３０４。

アプリケーションが開始すると、アプリケーションは、ローカル計算デバイスに格納された一組のセキュリティパーミッションをロードする。アプリケーションは、または多くのクラスリポジトリ、および各リポジトリが要求するパーミッションを承知するように構成される。アプリケーションは、その後、一組のセキュリティクラスローダを初期化して各リポジトリからクラスをロードする。各セキュリティクラスローダは、リポジトリの１つからクラスをロードするように構成され、リポジトリによって要求されるセキュリティパーミッションを把握する。前述したように、クラスリポジトリは、計算デバイスにローカルである、またはサーバを通してリモートでアクセス可能である。

アプリケーションは、ハードウエア、ソフトウエア、ファームウエア、または、ハードウエア、ソフトウエアおよび／ないしはファームウエアの組合せで実施される。ハードウエアの実施形態では、アプリケーションは、図５に示すように、メモリ６２と操作可能に関連付けられるプロセッサ６１において実行される。メモリ６２は、図６に示すように、プロセッサ６１により、実行可能な命令セット４００を格納する。命令セットにより、プロセッサ６１は、メモリ６２に格納され得るセキュリティトークンをデコードする（ステップ４０１）ことが可能となる。デコードされると、プロセッサ６１は、セキュリティトークンで指し示されるセキュリティパーミッションを決定し（ステップ４０２）、セキュリティパーミッションと関連付けられるクラスリポジトリを選択する（ステップ４０３）。プロセッサ６１は、選択されたリポジトリからクラスをロードする（ステップ４０３）。

プロセッサ６１は、多数のクラスリポジトリを格納するメモリ７２と関連付けられるクラスリポジトリプロセッサのように、第２のプロセッサ７１と通信できる。アプリケーションのプロセッサ６１は、適した通信リンク６５を通じて、クラスの要求をクラスリポジトリのプロセッサ７１へ送信できる。

本発明の実施形態について添付の図面に示され、前述の記述で説明したが、本発明は開示された実施形態に限定されず、以下の特許請求の範囲に記載および定義される本発明の趣旨を逸脱することなしに、多数の再配置、修正、および置換が可能であることが理解されよう。たとえば、本発明の機能は、ブロック、モジュール、プロセッサ、またはメモリのうちの１つまたは複数によって完全におよび／または部分的に実行することができる。また、これらの機能は、本形式でまたは分散方式で、ならびに、情報を提供および／もしくは受信することができる任意の装置上でまたはそれを介して、実行されることができる。さらに、特定の態様で描かれているが、さまざまなモジュールまたはブロックが、本発明の範囲を逸脱することなしに、再配置されることができる。またさらに、特定の態様で描かれているが、本発明を完遂するために、追加の知られている特徴を本発明に提供するために、および／または本発明をさらに効率的にするために、より多くのもしくは少ない数のモジュールおよび接続を利用することができる。また、さまざまなモジュールの間で送信される情報は、データネットワーク、インターネット、インターネットプロトコルネットワーク、無線ソース、および有線ソースのうちの少なくとも１つを介して、ならびに複数のプロトコルを介して、モジュールの間で送信することができる。

Claims (20)

1. アプリケーションにおけるクラスをロードする方法であって、
   クラスの要求を決定するステップと、
   セキュリティパーミッションを決定するステップと、
   前記セキュリティパーミッションに関連付けられた要求された前記クラスのクラスバリアントを検索するステップと、
   前記検索されたクラスバリアントをロードするステップと
   を含むことを特徴とする方法。
2. セキュリティパーミッションを決定するステップは、セキュリティトークンをデコードするステップを含むことを特徴とする請求項１に記載の方法。
3. クラスの要求を決定するステップは、要求ハンドラにおけるクラスの呼び出しを受信するステップを含み、かつ、セキュリティパーミッションを決定するステップは、前記要求ハンドラにおけるセキュリティトークンをデコードするステップを含むことを特徴とする請求項１に記載の方法。
4. 前記クラスバリアントのリポジトリを選択するステップと、
   前記選択されたリポジトリから前記クラスをロードするステップと
   を含むことを特徴とする請求項１に記載の方法。
5. 前記クラスの要求から前記セキュリティパーミッションを決定するステップを含むことを特徴とする請求項１に記載の方法。
6. クラスに対する複数のクラスバリアントを確立するステップと、
   クラスバリアントの各々とセキュリティパーミッションと関連付けるステップと
   を含むことを特徴とする請求項１に記載の方法。
7. 別々のリポジトリにおける前記クラスバリアントを格納するステップを含むことを特徴とする請求項６に記載の方法。
8. クラスのクラスバリアントの各々は、同一の名前空間を有することを特徴とする請求項６に記載の方法。
9. クラスのクラスバリアントの各々は、同一のパブリックのアプリケーションプログラミングインターフェースを提供することを特徴とする請求項６に記載の方法。
10. 第１のクラスバリアントは、第１の機能性を提供し、かつ、第２のクラスバリアントは、前記第１のクラスバリアントと比較して縮小した機能性を提供することを特徴とする請求項６に記載の方法。
11. セキュリティパーミッションの各々とクラスバリアントのリポジトリとを関連付けるステップを含むことを特徴とする請求項６に記載の方法。
12. 前記クラスバリアントは、同等のセキュリティパーミッションを有する１つまたは複数の他のクラスのクラスバリアントにより、リポジトリに格納されることを特徴とする請求項１１に記載の方法。
13. アプリケーションであって、
    要求ハンドラと、
    少なくとも１つのクラスローダとを含み、
    前記要求ハンドラは、
    クラスに対する要求を処理し、
    前記アプリケーションのセキュリティパーミッションを決定するように構成され、かつ、
    前記クラスローダは、前記セキュリティパーミッションに依存してクラスバリアントをロードするように構成されていることを特徴とするアプリケーション。
14. 前記クラスローダは、
    前記セキュリティパーミッションに依存して複数のクラスリポジトリからクラスリポジトリを選択し、かつ、
    前記選択されたクラスリポジトリから前記クラスバリアントをロードするように構成されていることを特徴とする請求項１３に記載のアプリケーション。
15. 前記複数のクラスリポジトリを含むことを特徴とする請求項１４に記載のアプリケーション。
16. 前記要求ハンドラは、前記セキュリティパーミッションを決定するためにセキュリティトークンをデコードするように構成されていることを特徴とする請求項１３に記載のアプリケーション。
17. 複数のクラスを含み、少なくとも１つのクラスは、複数のクラスバリアントを含むことを特徴とする請求項１３に記載のアプリケーション。
18. 第１のクラスバリアントは、第１の機能性を提供し、かつ、第２のクラスバリアントは、前記第１のクラスバリアントと比較して縮小した機能性を提供することを特徴とする請求項１７に記載のアプリケーション。
19. 前記第１のクラスバリアントは、第１のセキュリティパーミッションと関連付けられ、かつ、前記第２のクラスバリアントは、第２のセキュリティパーミッションと関連付けられることを特徴とする請求項１８に記載のアプリケーション。
20. プロセッサによる実行のためのコンピュータ実行可能命令を含むコンピュータ読取可能な媒体であって、前記命令が実行されるときに、前記プロセッサに、
    セキュリティトークンをデコードさせ、
    前記セキュリティトークンからセキュリティパーミッションを決定させ、
    前記セキュリティパーミッションに関連付けられたクラスリポジトリを選択させ、
    前記選択されたクラスリポジトリからクラスをロードさせる、
    ことを特徴とするコンピュータ読取可能な媒体。

Images