JP6556943B2 - アプライアンスセキュアシェルのためのシングルサインオン方法 - Google Patents

Description

本発明は、セキュアネットワーク通信の分野、より具体的には、ウェブリソースにアクセスするためのセキュアシェル接続を効率的に確立することに関する。

関連技術の説明

初期のクライアントサーバコンピューティングモデルは、複数のクライアントコンピューティングデバイスの各々の上で、及び支持されたクライアントサーバアプリケーション用のリモートサーバ上で、コードを利用した。クライアントコンピューティングデバイス用のコードは、ユーザインターフェイスを提供し、そのコードは、複数のクライアントコンピューティングデバイスの各々上でインストールされた。アップグレードは、複数のクライアントコンピューティングデバイスの各々上で、そのコードに変化を引き起こした。更に、クライアントコンピューティングデバイス及びサーバ用のコードは、典型的には、所与の命令セットアーキテクチャ（ＩＳＡ）及びオペレーティングシステム（ＯＳ）に依存した。

ウェブベースアプリケーションは、標準言語フォーマットによって作成されるウェブページを利用することによって、上記の問題のうちの多くに対処した。クライアントコンピューティングデバイス上のウェブブラウザは、要求されたウェブページを記憶するリモートウェブサーバに要求を伝送する。ウェブブラウザは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して、要求を転送する。リモートウェブサーバ上でホストされるアプリケーション用のクライアントコードは、特定のウェブページが成功してアクセスされるとき、クライアントコンピューティングデバイスにダウンロードされる。

アプリケーションをホストするリモートウェブサーバは、ユーザの特定のグループに対して、アプリケーションへのアクセスを制限し得る。クライアント−サーバコンピューティングモデルに対する初期のセキュリティ実行は、ＨＴＴＰ基本認証を使用したもので、ユーザは、ユーザがホストされたアプリケーションにアクセスすることを可能にする前に、ユーザを認証するために使用される資格情報を提供した。この種の認証は、ユーザが既に認証されたが、リモートウェブサーバを通して利用可能である他のリソースの各アクセスに関する資格情報をユーザに促す。更に、一旦ユーザが認証されると、コード化されたフォーマットにおいて資格情報を含み得るアプリケーションプログラミングインターフェイス（ＡＰＩ）キーが、各要求のヘッダにおいて使用される。認証されたユーザによって使用されるコンピューティングデバイスへのアクセスを取得する悪意のあるユーザは、コンピューティングデバイス上でアプリケーション用のクライアントコードをリバースエンジニアリングして、記憶されたＡＰＩキーを取得し得る。

トークン認証は、リモートウェブサーバ上でホストされるウェブベースアプリケーションにアクセスする各接続されたコンピューティングデバイスのトラッキングを提供し、ユーザが既に認証されたときに、リモートウェブサーバを通して利用可能である他のリソースのアクセスに関する資格情報を促さない。オペレーティングシステムは、アクセストークンのストレージを非表示にすることによって、追加のセキュリティを提供する。加えて、悪意のあるユーザがアクセストークンを取得する場合、アクセストークンは、潜在的な損失を制限する有効期限を有する。認証サービスを使用して、ユーザ資格情報を検証し、リモートウェブサーバ上のセッションの最中に使用されることになる一時的なアクセストークンを生成する。

トークン認証の生成及び維持は、複雑である。開発者は、トークン認証を支持及び維持するためのコードを書き込むことにかなりの量の時間を消費することよりもむしろ、ウェブベースアプリケーションを作成して、アプリケーションをオンラインにし、迅速に実行させることに時間を費やすことを好む。更に、多くの種類のタスク及び対応するウェブベースアプリケーションに対して、システム管理者などの特定のユーザは、セキュアシェル（ＳＳＨ）ユーザインターフェイスを使用することを好む。ＳＳＨユーザインターフェイスは、ＯＳ及びウェブベースアプリケーションにコマンドラインインターフェイス（ＣＬＩ）を提供する。しかしながら、システム管理者がウェブベースアプリケーションをホストするリモートウェブサーバ上でＨＴＴＰセッションを既に確立しているにもかかわらず、ＳＳＨアクセスは、典型的には、別のログインの試みをユーザに促す。認証サービスは、また、資格情報を検証する一方で、ＨＴＴＰリダイレクションを使用し得る。ＳＳＨユーザインターフェイスは、ＨＴＴＰリダイレクションを支持することができない。

上記を考慮して、ウェブリソースにアクセスするためのセキュアシェル接続を効率的に確立するための改善されたシステム及び方法が所望される。

ウェブリソースにアクセスするためのセキュアシェル接続を効率的に確立するためのシステム及び方法が想到されている。様々な実施形態では、ストレージサービスデバイスは、比較的小さなビジネス環境、又は代替的に、大きな企業環境などのビジネス環境において、複数のデバイスの間に配置される。ストレージサービスデバイスは、ストレージデバイスとも称され得る。複数のクライアントコンピューティングデバイスは、インターネット又はクラウドベースネットワークなどのネットワークにわたって、ストレージデバイスにリモート接続され得る。その環境は、第三者認証サービスを含み得、それは、制限されたアクセスでリモートストレージデバイス上のウェブリソースに対してユーザを認証することなどのユーザ管理に対処するためのアイデンティティプロバイダとも称される。

第三者アイデンティティプロバイダ（ＩＤＰ）は、１つ以上のハイパーテキスト転送プロトコル（ＨＴＴＰ）リダイレクションを使用する一方で、ユーザを認証する工程を実行する。ＨＴＴＰリダイレクションは、クライアントコンピューティングデバイス上のユーザのウェブブラウザによって、及びストレージデバイス上のウェブサービスによって支持される。しかしながら、ＨＴＴＰリダイレクションは、クライアントコンピューティングデバイスとリモートストレージデバイスとの間でセキュアシェル接続を確立するために使用されるセキュアシェル（ＳＳＨ）コード（プロセス）によって支持されない。

成功した認可がＳＳＯアイデンティティプロバイダを用いて達成された後、ストレージデバイスは、クライアントコンピューティングデバイスにアクセストークン及びオプションのリフレッシュトークンを送信し得る。更に、ストレージデバイスは、セッションクッキー、インターネットプロトコル（ＩＰ）アドレス、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの１つ以上を含むクライアントデバイス識別子（ＩＤ）を送信し得る。ストレージデバイスは、アクセストークン及び／又はオプションのリフレッシュトークン、並びにクライアントデバイスＩＤを記憶し得る。少なくとも記憶されたアクセストークン及び記憶されたクライアントデバイスＩＤは、ユーザがテキストベースセキュアシェルセッションを要求するとき、第三者アイデンティティプロバイダを使用せずにユーザを認証するために、後で使用され得る。少なくとも記憶されたアクセストークンを使用して、ストレージデバイス上でウェブリソースに対してクライアントデバイスからのアクセス要求を認証し得る。。この点において、セキュアＨＴＴＰセッションは、クライアントコンピューティングデバイスとリモートストレージデバイスとの間でユーザのために確立される。ユーザは、セキュアＨＴＴＰセッションを使用して要求を送信し得、要求は、少なくともアクセストークン及び／又はオプションのリフレッシュトークン、並びにクライアントデバイスＩＤを含む。

後で、ユーザは、ストレージデバイス上のウェブアプリケーションに、クライアントコンピューティングデバイスとストレージデバイスとの間のテキストベースセキュアシェル（ＳＳＨ）接続を確立することを要求し得る。様々な実施形態では、要求は、ユーザ名、アクセストークン及び／又はオプションのリフレッシュトークン、並びにクライアントデバイスＩＤを含む。テキストベースセキュアシェル（ＳＳＨ）セッションに関して、リモートストレージデバイス上で要求をウェブアプリケーションに送信するとき、ユーザは、ログイン資格情報を促されない。加えて、テキストベースＳＳＨセッションに関して、ユーザを認証する工程の最中に、ユーザは、ログイン資格情報を促されない。

リモートストレージデバイスは、テキストベースＳＳＨセッションに関する要求を受信し、第三者アイデンティティプロバイダを使用せずにユーザをローカルに認証する。むしろ、リモートストレージデバイスは、ユーザ名と一緒に、以前に記憶されたアクセストークン及び／又はリフレッシュトークン、並びにクライアントデバイスＩＤを使用し得る。アイデンティティ及びアクセスマネージャ（ＩＡＭ）は、ユーザを認証するためにリモートストレージデバイスによって使用され得る。ＨＴＴＰリダイレクションは、認証を実行するために使用されない。いくつかの実施形態では、セキュアＨＴＴＰセッションに関して生成されるトークン（複数可）とは別個のアクセストークン及びオプションのリフレッシュトークンの対は、テキストベースセキュアシェルセッションに対して作成される。他の実施形態では、セキュアＨＴＴＰセッションに対して使用される同じアクセストークン及びオプションのリフレッシュトークンの対は、テキストベースセキュアシェルセッションに対して使用される。リモートストレージデバイスは、ＳＳＨセッションに対して認証されているユーザの通知を、クライアントコンピューティングデバイスに送信する。第三者アイデンティティプロバイダがシステム内で使用されるが、ユーザは、資格情報を要求するログイン工程を伴わずに、クライアントコンピューティングデバイスとリモートストレージデバイスとの間のテキストベースセキュアシェル接続を使用することができる。ユーザは、クライアントコンピューティングデバイス上のウェブブラウザ内でコマンドラインインターフェイス（ＣＬＩ）を用いて提示され得る。

これら及びその他の実施形態は、以下の説明及び添付図面の参照によって理解されるであろう。

第三者シングルサインオン（ＳＳＯ）サービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを確立する一実施形態を図解する汎用ブロック図である。

第三者ＳＳＯサービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを確立することを継続する一実施形態を図解する汎用ブロック図である。

第三者ＳＳＯサービスを使用してセキュアＨＴＴＰセッションを確立した後にリモートストレージデバイス上でテキストベースセキュアシェルセッションを確立する一実施形態を図解する汎用ブロック図である。

第三者ＳＳＯサービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを確立するための方法の一実施形態を図解する流れ図である。

第三者ＳＳＯサービスを使用してセキュアＨＴＴＰセッションを確立した後にリモートストレージデバイス上でテキストベースセキュアシェルセッションを確立するための方法の一実施形態を図解する流れ図である。

本発明は、様々な修正及び代替的な形態が可能であるが、具体的な実施形態が、図面において、例として示されており、かつ本明細書において詳細に説明される。しかしながら、図面及びその詳細な説明は、本発明を開示される特定の形態に制限することを意図するものではなく、逆に、本発明は、添付の特許請求の範囲で定義されるように、本発明の趣旨及び範囲内に入る全ての修正、同等、及び代替を網羅するものであることを理解されたい。

以下の説明では、数々の具体的な詳細が、本発明の十分な理解をもたらすために記載されている。しかしながら、当業者であれば、本発明がこれらの具体的な詳細なしで実施され得ることを認識するであろう。場合によっては、周知の回路、構造、信号、コンピュータプログラム命令、及び技術は、本発明を不明瞭にすることを避けるため、詳細に示されていない。

ストレージサービスデバイス（ストレージデバイスとも称され得る）は、様々なビジネス又は他の環境のいずれにおいても、配置され得る。いくつかの実施形態では、ストレージデバイスは、リモートウェブベースバックアップサーバである。他の実施形態では、ストレージデバイスは、バックアップ専用アプライアンス（ＰＢＢＡ）又はストレージアプライアンスであり得る。かかる環境では、複数のクライアントコンピューティングデバイス（クライアントデバイス）は、インターネット又はクラウドベースネットワークなどのネットワークにわたって、ストレージデバイスにリモート接続され得る。かかるクライアントコンピューティングデバイスの例としては、デスクトップコンピュータ、ラップトップ、タブレットコンピュータ、スマートフォンなどが挙げられる。

クライアントデバイスで作業をする１人以上のユーザに対して、ストレージデバイスは、ストレージデバイス上でホストされるリソースへの制限されたアクセスを提供し得る。いくつかの実施形態では、その環境は、第三者認証サービスを含み得、それは、制限されたアクセスなどのユーザ管理に対処するためのアイデンティティプロバイダとも称される。第三者アイデンティティプロバイダ（ＩＤＰ）は、シングルサインオン（ＳＳＯ）サービスを使用し得る。ＳＳＯサービスを用いて、ユーザは、最初のログインの後にアクセスされる別個のアプリケーションの数に関係なく、一度だけ資格情報を提供する。上記に加えて、第三者アイデンティティプロバイダ（ＩＤＰ）は、１つ以上のＨＴＴＰリダイレクションを使用する一方で、ユーザを認証する工程を実行し得る。ＨＴＴＰリダイレクションは、概して、クライアントデバイス上のユーザのウェブブラウザによって、及びストレージデバイス上のウェブサービスによって支持される。しかしながら、かかるＨＴＴＰリダイレクションは、ストレージデバイスに対するセキュア接続を確立するために使用されるセキュアシェル（ＳＳＨ）コード（プロセス）によって支持されない。

以下の考察において、図１及び図２は、セキュアＨＴＴＰセッションを確立するための実施形態を図解する。セキュアＨＴＴＰセッションの確立の後、図３は、ユーザログインの促しを伴うことなく、かつ第三者アイデンティティプロバイダを使用することなく、セキュアシェルセッションの確立を描写する。最後に、図４及び図５の各々は、クライアントデバイスのためにストレージデバイス上でセキュアＨＴＴＰセッション及びテキストベースセキュアシェルセッションを確立するための方法を図解する。

図１を参照すると、第三者シングルサインオン（ＳＳＯ）サービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを確立する一実施形態の汎用ブロック図が示される。示された実施形態では、単一クライアントコンピューティングデバイス１１０は、ストレージサービスデバイス１２０に接続される。しかしながら、様々な他の実施形態では、複数のクライアントコンピューティングデバイスは、ストレージサービスデバイス１２０に接続され、１つ以上の他のデバイス又はサーバに接続される。他の複数のデバイス及びサーバは、説明を容易にするために示されていない。クライアントコンピューティングデバイス１１０は、クライアントデバイス１１０とも称され得る。ストレージサービスデバイス１２０は、ストレージデバイス１２０とも称され得る。クライアントデバイス１１０はまた、第三者アイデンティティプロバイダ１５０に接続されて示される。アイデンティティプロバイダ１５０は、ディレクトリサービス及び認証サービスのうちの１つ以上を提供するための、１つ以上のサーバ（serves）１３０〜１４０及びソフトウェアを含み得る。

クライアントデバイス１１０の例としては、少なくともデスクトップコンピュータ、ラップトップ、タブレットコンピュータ、スマートフォンなどが挙げられる。いくつかの実施形態では、ストレージデバイス１２０は、ディスクストレージ、バックアップサーバ、ネットワークアタッチトストレージ（ＮＡＳ）デバイス、ストレージエリアネットワーク（ＳＡＮ）デバイス、又は他のものなどのストレージの一種である。他の実施形態では、ストレージデバイス１２０は、バックアップ専用アプライアンス（ＰＢＢＡ）である。ＰＢＢＡは、ストレージアプライアンスとも称され得る。典型的に、ストレージアプライアンスは、ソフトウェアと一緒に販売される、一般的に使用される認定サーバハードウェアに基づくサーバであり、ハードウェア及びソフトウェアは単一の供給メーカーによって提供される。ストレージアプライアンスは、サーバ、データストレージ、オペレーティングシステム、バックアップソフトウェア、及び重複排除ソフトウェアを含み得る。ストレージアプライアンスの一体型アプローチは、相対的に迅速なインストール（配置）時間をもたらし得る。ストレージアプライアンスは、ストレージを提供し、別のアプライアンス又は別のストレージ媒体でのストレージを可能にし、かつ／又は物理システム及び仮想システムの両方の重複排除を提供し得る。

ストレージアプライアンスは典型的に、４テラバイト（ＴＢ）〜５００ＴＢの容量を有するデータストレージを提供する。結果として、ストレージアプライアンスは、テープベースバックアップ及びリカバリプロセスに取って代わり得る。企業環境及びメインフレーム環境などの他の環境では、ストレージアプライアンスは、テープベースシステムと一緒に配置され得る。ストレージアプライアンスは、クラウドベースストレージに、又は構内ストレージで使用され得る。クライアントデバイス１１０とストレージデバイス１２０と間の接続は、少なくともインターネットを含み得、クライアントデバイス１１０及びストレージデバイス１２０の各々は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して、メッセージを転送する。

様々な実施形態では、クライアントデバイス１１０は、予め定義された汎用命令セットアーキテクチャ（ＩＳＡ）に従って命令を実行するための回路機構を含む１つ以上のプロセッサコアを含み得る。例えば、ＳＰＡＲＣ（登録商標）命令セットアーキテクチャ（ＩＳＡ）が選択され得る。代替的に、ｘ８６、ｘ８６−６４（登録商標）、Ａｌｐｈａ（登録商標）、ＰｏｗｅｒＰＣ（登録商標）、ＭＩＰＳ（登録商標）、ＰＡ−ＲＩＳＣ（登録商標）、又は任意の他のＩＳＡが選択され得る。他の実施形態では、クライアントデバイス１１０は、１つ以上のプロセッサが、非常に広い単一命令多重データ（ＳＩＭＤ）アーキテクチャを利用して、高データ並列アプリケーションにおいて高スループットを達成するシステムオンチップ（ＳＯＣ）を含み得る。例えば、クライアントデバイス１１０は、グラフィック処理ユニット（ＧＰＵ）、デジタル信号プロセッサ（ＤＳＰ）などのうちの１つ以上を含み得る。

クライアントデバイス１１０は、Ｍａｃ ＯＳ Ｘオペレーティングシステム、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓオペレーティングシステム、Ｕｎｉｘ系オペレーティングシステム、モバイルデバイスオペレーティングシステム、又はハードディスクが複数のオペレーティングシステムをホストするように区画化される組み合わせを使用し得る。前に説明したように、クライアントデバイス１１０の例としては、少なくともデスクトップコンピュータ、ラップトップ、タブレットコンピュータ、スマートフォンなどが挙げられる。クライアントデバイス１１０は、ウェブブラウザ１１２などのソフトウェアを含み得る。ウェブブラウザ１１２は、少なくともＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｆｉｒｅｆｏｘ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、及びＳａｆａｒｉなどのいくつかの利用可能なワールドワイドウェブブラウザで表したものであり得る。

様々な実施形態では、ウェブベースユーザインターフェイス１１４は、ストレージデバイス１２０上のアプリケーション１２４用のウェブブラウザ１１２内のグラフィカルユーザインターフェイス（ＧＵＩ）であり得る。いくつかの実施形態では、ユーザ１０２が認可されるまで、ウェブベースアプリケーションユーザインターフェイス１１４は、クライアントデバイス１１０のモニタ上でユーザ１０２に提示されない場合がある。ウェブベースアプリケーションユーザインターフェイス１１４は、使い勝手のよいインターフェイスをユーザに提供し得る。当業者に周知であるように、ＧＵＩウェブベースアプリケーションユーザインターフェイス１１４は、バッチジョブの送信などの効率的な自動操作シーケンスに対する十分な支持を欠く場合がある。

ストレージデバイス１２０は、少なくともオペレーティングシステム（ＯＳ）、ウェブサービス１２２、及び少なくとも１つのウェブベースアプリケーション１２４などの複数のソフトウェア構成要素を含み得る。ＯＳ（図示せず）は、例えば、Ｓｙｍａｎｔｅｃ Ａｐｐｌｉａｎｃｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ、Ｌｉｎｕｘ（登録商標）、又はＳｕｎ Ｓｏｌａｒｉｓなどの様々な特定のオペレーティングシステムのいずれかを表したものであり得る。このように、オペレーティングシステムは、システム管理者のために、重複排除、自動バックアップ、リカバリ操作のためのウェブベースアプリケーション１２４などの様々なプログラムの実行を支持するように動作可能なソフトウェアフレームワークを提供するように動作可能であり得る。ウェブサービス１２２は、認証を検証し、認可されたユーザのためにウェブベースセッション及びテキストベースシェルセッションを作成し得る。

ストレージデバイス１２０によって実行される企業情報管理において使用される操作などのデータ管理操作は、企業コンプライアンスを提供する。企業コンプライアンスは、ファイル及びレポートに保持されるデータの精度及び完全性、並びに企業全体での一貫性のあるデータを保証する。企業環境及びスモールビジネス環境の両方とも、上記のデータ管理操作を提供するために複数のストレージデバイスを配置し得る。前に説明したように、ストレージデバイスはストレージアプライアンスである。加えて、環境は、ローカルに及び／又はリモートに１つ以上のストレージデバイスにログインし得る複数のユーザを支持するために、複数のクライアントデバイスを配置し得る。

ユーザは、概して、特権、許可、及び役割を含む構成情報を有する。多くの事例では、このユーザ構成情報は、いくつかのデバイスにわたり、所与のユーザに関して一貫性であり得る。企業環境は典型的に、ユーザディレクトリサービスを使用して、デバイス上で認可されたユーザのアイデンティティを管理する。示されるように、ストレージデバイス１２０は、ディレクトリサービス操作及びユーザ認証操作のために第三者アイデンティティプロバイダ１５０を使用する。第三者アイデンティティプロバイダ１５０を使用して、開発者が、ディレクトリサービス及び認証サービスも支持するよりはむしろ、ストレージデバイス１２０上でホストされるウェブベースアプリケーションを作成することに主眼を置くことを可能にし得る。

第三者アイデンティティプロバイダ１５０は、また、ウェブサービス１３２を使用して、少なくともクライアントデバイス１１０と通信する。クライアントデバイス１１０、ストレージデバイス１２０、及びアイデンティティプロバイダ１５０の各々は、少なくともハイパーテキスト転送プロトコル（ＨＴＴＰ）を利用して、通信する。いくつかの実施形態では、第三者アイデンティティプロバイダ１５０は、シングルサインオン（ＳＳＯ）サービス１３４を使用する。他の実施形態では、第三者プロバイダは、集中認証プロセスを使用し得る。ユーザが認可されたＨＴＴＰセッションを有するときでさえ、ユーザ１０２が別個のアプリケーションの各アクセスに関する資格情報を促される集中認証プロセスとは対照的に、ユーザ１０２は、ＳＳＯサービス１３４を用いて認可されたＨＴＴＰセッションに対して一度だけ認証される。

ＳＳＯサービス１３４を用いて、ユーザ１０２は、認可されたＨＴＴＰセッションに対する最初のログインの後にアクセスされる別個のアプリケーションの数に関係なく、ユーザ名及びパスワードなどの資格情報を一度だけ提供する。ＳＳＯサービス１３４によって提供されるアクセストークン及びオプションのリフレッシュトークンは、それらが権利を与えられた全てのアプリケーションに関して、ユーザ１０２を認証し、ユーザ１０２が、特定の認可されたＨＴＴＰセッションの最中にアプリケーションをスイッチするときの、資格情報の更なる促しを排除する。ＳＳＯアイデンティティプロバイダのいくつかの例としては、Ｓｔｏｒｍｐａｔｈ、ＯｎｅＬｏｇｉｎ、ＰｉｎｇＯｎｅ、Ｋｅｙｃｌｏａｋ、及びＡｕｔｈ０が挙げられる。後述するように、第三者プロバイダが集中認証プロセスを使用するときでさえ、ユーザ１０２は、一度だけ認証されて、認証されたＨＴＴＰセッションを通して複数のアプリケーションへのアクセスを獲得して、ユーザ名及びパスワードなどの資格情報を促されることなく、認証されたテキストベースセキュアシェルセッションへのアクセスを獲得し得る。

セキュアＨＴＴＰセッションに対してユーザ１０２を認証するための一連の８つの工程が、図１に示される。一連の工程は、図２に継続し、ここでは、ユーザ１０２が、セキュアＨＴＴＰセッションを確立して、ウェブベースアプリケーション１２４にアクセスする。一連の工程は、図３に継続し、ここでは、ユーザ１０２が、ログイン資格情報を促されることなくセキュアテキストベースシェルセッションに対して認可される。少なくともクライアントデバイス１１０、ストレージデバイス１２０、及びアイデンティティプロバイダ１５０を使用する環境は、ウェブベースアプリケーション及びクラウドベースアプリケーションを利用して、ストレージデバイス１２０上のアプリケーション１２４などのデータを管理し得る。いくつかの実施形態では、アプリケーション１２４は、ウェブベースバックアップ及びリカバリアプリケーションである。代替的に、アプリケーション１２４は、ボリュームを作成、修正、及び除去するウェブベースアプリケーションである。加えて、アプリケーション１２４は、ファイルシステムを作成、マウント、及び共有し得る。

一般的に述べると、ウェブリソースは、作成、修正、レンダリング、除去、及び読み出しなどのためにウェブベース及びクラウドベースアプリケーションによって使用される、ソフトウェア構成要素、アーティファクト、又はデータ及びメタデータである。ウェブリソースは、ファイル、ドキュメント、ストレージボリューム、及びウェブベース識別子の任意の他のターゲットを含み得る。ウェブベース識別子は、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソース識別子（ＵＲＩ）、国際化リソース識別子（ＩＲＩ）などを含み得る。ウェブリソースは、典型的には、ウェブベースアプリケーション用のルートディレクトリのサブディレクトリなどにおける位置において収集される。いくつかの例では、サブディレクトリは、リソース／リソース識別子として示され得る。

ウェブリソース識別子は、［ｌｏｃａｌｅ−ｐｒｅｆｉｘ／］［ｌｉｂｒａｒｙ−ｎａｍｅ／］［ｌｉｂｒａｒｙ−ｖｅｒｓｉｏｎ／］ｒｅｓｏｕｒｃｅ−ｎａｍｅ［／ｒｅｓｏｕｒｃｅ−ｖｅｒｓｉｏｎ］などの所与のフォーマットに適合する固有文字列である。ＵＲＬの使用を例に取ると、ウェブリソースＵＲＬは、アプリケーション１２４がウェブリソースにアクセスするために使用するアドレスである。ウェブリソースがバックアップ及びリカバリアプリケーションに接続されるバックアップサーバである場合、対応するアドレスは、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：９３９９／ａｐｉ／ｂａｃｋｕｐＳｅｒｖｅｒｓ／７９４６０３５４−ｅ７ｃ８−６ｄｆ２−４５ａ７−０１ｄｆ２ｂｃｄ９ｂ２ａなどのフォーマットを使用し得る。フォーマットは、ベースＵＲＬ及びウェブリソース位置を含む。

ここでは、ベースＵＲＬは、バックアップ及びリカバリアプリケーションのＲＥＳＴｆｕｌ ＡＰＩへのエントリポイントであり、これは間もなく更に説明される。この例におけるベースＵＲＬは、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：９３９９／ａｐｉ／である。「ｌｏｃａｌｈｏｓｔ」という文字列は、バックアップ及びリカバリアプリケーションがインストールされている機械の名称である。例えば、この文字列は、図１に示される例において、ストレージデバイス１２０を特定し得る。「９３９９」という文字列は、ウェブリソースにアクセスするために使用されるサーバ１７０上で、ウェブサービスと関連付けられるＲＥＳＴ ＡＰＩと通信するために使用されるポートである。

上記の例におけるウェブリソース位置は、／ｂａｃｋｕｐＳｅｒｖｅｒｓ／７９４６０３５４−ｅ７ｃ８−６ｄｆ２−４５ａ７−０１ｄｆ２ｂｃｄ９ｂ２ａである。ウェブリソース位置は、バックアップ及びリカバリアプリケーションのＲＥＳＴｆｕｌ ＡＰＩにおいて、ウェブリソース自体へのパスを特定する。ウェブリソース位置は、ベースＵＲＬに接尾辞を付け、ウェブリソース用のＵＲＬを形成する。ウェブリソース位置は、ユニフォームリソース名（ＵＲＮ）を含み得る。ＵＲＬ及びＵＲＮの両方は、ユニフォームリソース識別子（ＵＲＩ）である。しかしながら、ＵＲＮは、また、ユーザが、作成者名、タイムスタンプ、データサイズなどのＵＲＮにおいてウェブリソースと関連付けられた記述情報を追加すること可能にするユニフォームリソース特性（ＵＲＣ）と関連付けられる。更に、ＵＲＮは、ウェブリソースを固有に特定するエンティティ識別子（ＩＤ）又はキーを含み得る。上記の例において、キーは７９４６０３５４−ｅ７ｃ８−６ｄｆ２−４５ａ７−０１ｄｆ２ｂｃｄ９ｂ２ａである。名称の例として、所与のバッチ用のジョブセットアップなどのジョブの収集にアクセスすることは、ＵＲＮ／ｊｏｂｓ７によって特定され得る。完全なＵＲＬは、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ：９３９９／ａｐｉ／ｊｏｂｓ７であり得る。

上記の例におけるキー値は、バックアップ及びリカバリアプリケーションのＲＥＳＴｆｕｌ ＡＰＩワークセッションの時間の最中にのみ、関連付けられたウェブリソースを特定するために有効なままであり得る。アプリケーションのＲＥＳＴｆｕｌ ＡＰＩワークセッション、又はその例におけるアプリケーション１２４用のワークセッションは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）セッションとも称され得る。ＨＴＴＰプロトコルは、「Ｗｅｂ（ウェブ）」又は「ｗｅｂ（ウェブ）」とも称されるワールドワイドウェブ上でデータ通信のために使用される。ウェブは、インターネットを介してアクセスされる、相互リンクされたハイパーテキストドキュメント（ウェブページ）、及び上記のウェブリソースなどの他のデジタルリソースの情報システムである。

様々な実施形態では、インターネットなどのネットワークにわたってクライアントデバイス１１０とストレージデバイス１２０との間で、ウェブサービスとして知られるプロセスによって維持される機械間（クライアント−サーバ）データ通信は、一組のステートレス操作を使用してウェブリソースの操作を可能にし得る。このデータ通信において使用されるウェブアプリケーションプログラミングインターフェイス（ＡＰＩ）は、比較的単純なより単純な表現状態の転送（ＲＥＳＴ）通信を使用し得る。ＲＥＳＴを使用するＡＰＩは、ＲＥＳＴｆｕｌ ＡＰＩと称される。ＲＥＳＴｆｕｌ ＡＰＩは、トランザクションを細分化して、各々が完全なトランザクションの特定の根底にある機能を実行する一連のより小さなトランザクションを作成する。このモジュール性は、開発者に柔軟性を提供する。

ＲＥＳＴアーキテクチャスタイルは、ウェブブラウザ内でウェブＡＰＩによって使用される。ウェブベースアプリケーション及びクラウドベースアプリケーションの使用の増加に伴い、ＲＥＳＴｆｕｌ ＡＰＩなどの様々なＡＰＩは、ウェブサービスを公開するために出現している。ＲＥＳＴｆｕｌ ＡＰＩは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）にわたって、ＨＴＴＰ動詞又は方法を用いて通信する。ＨＴＴＰ方法（動詞）は、特定されたウェブリソース上で実行されるアクションを示す。ウェブリソースは、既存のデータを表し得る。代替的に、ウェブリソースは、動的に生成されたデータを表し得る。ＨＴＴＰ／１．０仕様は、ＨＴＴＰ方法（動詞）であるＧＥＴ、ＰＯＳＴ、及びＨＥＡＤを定義する。ＨＴＴＰ／１．１仕様は、ＨＴＴＰ方法（動詞）であるＯＰＴＩＯＮＳ、ＰＵＴ、ＤＥＬＥＴＥ、ＴＲＡＣＥ、及びＣＯＮＮＥＣＴを更に定義する。

図１に示される一連の工程に戻って、工程１におけるユーザ１０２は、ストレージデバイス１２０によってホストされる特定のウェブサイト上で、アプリケーション１２４などのウェブリソースにアクセスすることを試みる。アクセス要求は、クライアントデバイス１１０とストレージデバイス１２０との間のセキュアＨＴＴＰセッションの要求である。工程２では、ウェブサービス１２２は、ユーザ１０２が現在認可されていないか、ストレージデバイス１２０とのセキュアＨＴＴＰセッションに対する有効なログインを現在有しない。ウェブサービス１２２は、要求されたアプリケーション１２４のウェブサイトに対して、インターネット上のアドレス又はユニフォームリソースロケータ（ＵＲＬ）などの位置識別子を記憶する。

工程３では、ウェブサービス１２２は、第三者アイデンティティプロバイダ（ＩＤＰ）１５０のシングルサインオン（ＳＳＯ）サービス１３４（ウェブリソース）を特定するウェブブラウザ１１２に、応答を送信する。応答は、ＳＳＯサービス１３４の宛先ユニフォームリソース識別子（ＵＲＩ）を含むヘッダを用いてのＨＴＴＰリダイレクト応答であり得る。応答は、また、ＵＲＬクエリ変数としてコード化される認証要求も含み得る。工程４では、ウェブブラウザ１１２は、ウェブサービス１２２から受信される応答に基づいて、ＳＳＯサービス１３４に要求を送信する。ＳＳＯサービス１３４は、ユーザ１０２が、デフォルト又は要求された認証ポリシー要件を満たす既存の有効ログインＨＴＴＰセッションを有するかどうかを判定する。要件は、ウェブサービス１２２によって送信される認証要求において設けられ得る。

ＳＳＯサービス１３４は、ユーザ１０２が有効なＨＴＴＰセッションをまだ有していないと判定するとき、工程５において、ＳＳＯサービス１３４は、資格情報をユーザ１０２に促す。工程６では、ウェブブラウザ１１２は、ユーザ１０２によって提供されるログイン資格情報を用いて応答を送信する。資格情報は、少なくともユーザ名及びパスワードを含み得る。クライアントデバイス１１０からアイデンティティプロバイダ１５０へのログイン要求は、ユーザ１０２によって提供されるパスワードの暗号化されたバージョンを含み得る。クライアントデバイス１１０は、セキュアソケットレイヤ（ＳＳＬ）を使用して、アイデンティティプロバイダ１５０にログイン要求を送信し得る。

工程７では、アイデンティティプロバイダ１５０は、ユーザ１０２によって提供される少なくともユーザ名及びパスワードの組み合わせなどの受信された資格情報が、ユーザ１０２に関する記憶された資格情報に整合するかどうかを判定する。資格情報が整合する場合、アイデンティティプロバイダ１５０は、また、ユーザ１０２に関するシステム管理者役割又は正規のユーザ役割及び対応する特権などのユーザ１０２に関するユーザ役割情報を取得し得る。加えて、アイデンティティプロバイダ１５０は、認可アサーションを生成する。認可アサーションは、ユーザに関する成功した認可を示す１つ以上のトークン、キー、又は他の値を含み得る。アイデンティティプロバイダ１５０は、アクセストークン及びリフレッシュトークンの両方を生成し得る。アイデンティティプロバイダ１５０は、ＳＡＭＬ、ＳＰＮＥＧＯ、及びＸ．５０９などの１つ以上のセキュリティトークンの種類を支持し得る。加えて、ストレージデバイス１２０は、これらのセキュリティトークンの種類を支持し得る。

工程８では、アイデンティティプロバイダ１５０は、ユーザ１０２に関する成功した認可を示す応答を準備する。アイデンティティプロバイダ１５０におけるＳＳＯサービス１３４は、少なくとも認可アサーションを用いてユーザ１０２に関するログオンセキュリティコンテキストなどの応答情報を含むＨＴＭＬ形態を作成し得る。アイデンティティプロバイダ１５０は、ＨＴＭＬ形態をＨＴＴＰ応答に挿入する。ＨＴＭＬ形態は、典型的には、宛先サイトに形態を自動的に掲示するスクリプトコードを含む。ＨＴＴＰ応答は、クライアントデバイス１１０に送信される。

上記の説明が便宜上特定の一連の工程を説明するが、様々な実施形態において、行われている工程の順序が異なり得ることに留意されたい。更に、図示しない他の工程が含まれ（include）得、いくつかの実施形態では、いくつかの工程は組み合わされ得、いくつかの工程は排除され得る。例えば、上記の説明は、サービスプロバイダ開始ＳＳＯプロセスを説明し、本プロセスでは、クライアントデバイス１１０は、サービスプロバイダ、又は本例ではストレージデバイス１２０と最初に通信する。アイデンティティプロバイダ開始ＳＳＯプロセスを有することも可能であり、本プロセスでは、クライアントデバイス１１０は、アイデンティティプロバイダ１５０と最初に通信する。かかる全ての実施形態が想到されている。

ここで図２に戻ると、第三者ＳＳＯサービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを確立することを継続する一実施形態の汎用ブロック図が示される。前に記載された回路、制御論理、通信プロトコル、及びソフトウェアは、図１と同様に付番され、示される。一連の工程９〜１１が示される。クライアントデバイス１１０は、ユーザ１０２に関するセキュアＨＴＴＰセッションに対する成功した認証を示す応答を受信している。工程９では、ウェブブラウザ１１２は、ストレージデバイス１２０上で、アイデンティティプロバイダ１５０からウェブサービス１２２に情報を転送する。ウェブブラウザ１１２は、自動送信スクリプトにより転送を実行し得る。スクリプトは、ストレージデバイス１２０上で、アイデンティティプロバイダ１５０からウェブサービス１２２にＨＴＴＰ形態を送信するＨＴＴＰ ＰＯＳＴ要求を命令する。

工程１０では、ストレージデバイス１２０は、クライアントデバイス１１０からＨＴＴＰ形態を受信し、デジタル署名にアクセスし、このデジタル署名を分析する。暗号デジタル署名は、アイデンティティプロバイダ１５０によってＨＴＴＰ形態に挿入された。暗号デジタル署名は、公開キー及び対応する私用キーなどの非対称暗号化キーを使用する。私用キーは、秘密キーとも称され得る。私用キーは、アイデンティティプロバイダ１５０が、それが生成する認可応答に「署名する」ように、アイデンティティプロバイダ１５０用のデジタル署名を作成するために使用される。公開暗号化キーは、私用キーから作成されるデジタル署名を検証するために使用される。異なる公開キーが、私用キーによって作成されるデジタル署名を認証するために使用できないように、公開キー及び私用キーは互いに密接にリンクされる。

ストレージデバイス１２０は、デジタル署名を検査した後、アサーションコンテンツにおける情報を対応する記憶された値と比較する。アサーションコンテンツは、ユーザ役割、電子メールアドレス、及びアイデンティティ属性の他の証明などの１つ以上のユーザプロファイル属性を含む。このアクセスチェックが終わった場合、ストレージデバイス１２０は、ユーザ１０２に対してログオンセキュリティコンテキストのローカルバージョンを生成する。いくつかの実施形態では、ログオンセキュリティコンテキストは、ローカルアクセストークン及びローカルリフレッシュトークンを含む。アクセストークンは、所定の時間期間の最中にストレージデバイス１２０上でホストされるアプリケーション１２４などのリソースの各アクセスのためにセキュアＨＴＴＰセッションを使用して、ユーザ１０２を認証するために使用される。リフレッシュトークンは、元々のアクセストークンの期限後に新しいアクセストークンを生成するために使用される。更に、ストレージデバイス１２０は、セッションクッキー、別のセッション識別子、インターネットプロトコル（ＩＰ）アドレス、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの１つ以上を含むクライアントデバイス識別子（ＩＤ）を生成し得る。ストレージデバイス１２０は、クライアントデバイス１１０から後の要求に関して、受信されたアクセストークン及び／又はオプションのリフレッシュトークンか有効であるかどうかを判定するために、クライアントデバイス識別子を記憶し得る。いくつかの実施形態では、ウェブサービス１２２は、クライアントデバイス識別子（ＩＤ）を生成及び／又は記憶する。

様々な実施形態では、アプリケーション１２４は、ストレージデバイス１２０上で上記の工程を実行する。他の実施形態では、ストレージデバイス１２０上の別の構成要素は、図２に示される工程１０に関する上記の工程を実行する。ストレージデバイス１２０は、記憶された位置情報から、アプリケーション１２４と関連付けられた要求されたリソースＵＲＬを取得する。様々な実施形態では、ウェブサービス１２２は、記憶された位置情報を取得する。工程１１では、ストレージデバイス１２０は、ウェブブラウザ１１２にＨＴＴＰリダイレクト応答を送信して、アプリケーション１２４にアクセスする。様々な実施形態では、ウェブサービス１２２は、ＨＴＴＰリダイレクト応答を送信する。この点において、ユーザ１０２は、クライアントデバイス１１０において「ログオンされる」と考えられ、ストレージデバイス１２０上でセキュアＨＴＴＰセッションを有し、アプリケーション１２４にアクセスすることができる。

ここで図３に戻ると、第三者ＳＳＯサービスを使用してセキュアＨＴＴＰセッションを確立した後にリモートストレージデバイス上でテキストベースセキュアシェルセッションを確立する一実施形態の汎用ブロック図が示される。前に記載された回路、制御論理、通信プロトコル、及びソフトウェアは、図１と同様に付番され、示される。一連の工程が示される。クライアントデバイス１１０で作業するユーザ１０２は、ストレージデバイス１２０上で、認可されたセキュアＨＴＴＰセッションを通して、アプリケーション１２４へのアクセスを獲得している。示されるように、ストレージデバイス１２０は、セキュアシェルインターフェイス３２６及び認証管理モジュール３２８を含む。

セキュアシェルインターフェイス３２６は、セキュア（暗号化された）ネットワークプロトコル用のインターフェイスを支持するプロセスを提供するためのコードである。このセキュアネットワークプロトコルは、ストレージデバイス１２０上でＯＳのサービスにアクセスすることを可能にする。セキュアシェルインターフェイス３２６は、ストレージデバイス１２０上で、ＯＳ、アプリケーション１２４、及び他のソフトウェアアプリケーションのサービスに対するコマンドラインインターフェイス（ＣＬＩ）を提供する。ユーザ１０２がストレージデバイス１２０上でセキュアＨＴＴＰセッションに対して認可された後、ユーザ１０２は、ストレージデバイス１２０上でテキストベースセキュアシェルセッションの要求を開始し得る。いくつかの実施形態では、ウェブベースアプリケーションユーザインターフェイス１１４は、ストレージデバイス１２０上でテキストベースセキュアシェル（ＳＳＨ）セッションを要求するためのボタンを含み得る。要求を開始するための他の機構が可能であり、想到されている。テキストベースセキュアシェルセッションは、暗号化されたネットワークプロトコルを使用して、クライアントデバイス１１０とストレージデバイス１２０との間でメッセージを転送し得る。テキストベースセキュアシェルセッションの例としては、Ｗｉｎｄｏｗｓオペレーティングシステム上のＰｕＴＴＹ、及びＵｎｉｘ系オペレーティングシステム上のセキュアシェル（ＳＳＨ）が挙げられる。

ユーザ１０２は、テキストベースＳＳＨセッションを使用して、コマンドラインインターフェイス（ＣＬＩ）上でコマンドを入力し得る。例えば、ユーザ１０２は、ストレージデバイス１２０上のバッチジョブとして、固定シーケンスにおいていくつかのタスクを反復的に実行し得る。バッチジョブが条件付きコードを使用する場合、スクリプティングが言語Ｊａｖａ（登録商標）、Ｐｅｒｌ、Ｐｙｔｈｏｎなどで併用され得る。ＣＬＩコマンドは、ユーザによって対話式に入力されてもよく、ファイル内のＣＬＩに渡されてもよい。第三者アイデンティティプロバイダ１５０（図示せず）が、ＨＴＴＰリダイレクションによりユーザ認証のために使用されるとき、典型的には、テキストベースＳＳＨセッションを確立することは行われない。クライアントデバイス１１０上のウェブブラウザ１１２及びストレージデバイス上のウェブサービス１２２とは異なり、セキュアシェルインターフェイス３２６は、アイデンティティプロバイダ１５０によって実行されるＨＴＴＰリダイレクションに対処することができない。しかしながら、間もなく説明されるように、第三者アイデンティティプロバイダ１５０がユーザ認証のために使用されるときでさえ、他の工程は、テキストベースＳＳＨセッションを確立するために使用される。テキストベースセッション要求に対する認可は、ＨＴＴＰセッション要求に対する初期の認可に基づいているが、ユーザに資格情報を促すことなく達成され得る。

ストレージデバイス１２０上の認証管理モジュール３２８は、所与のユーザが、名乗っているユーザであることを確立又は検証するための方法を提供する。いくつかの実施形態では、認証管理モジュールは、プラグ可能認証管理（ＰＡＭ）モジュールである。認証管理モジュール３２８は、認証関連サービス用のモジュールのライブラリを含む、汎用ＡＰＩであるライブラリを含む。認証管理モジュール３２８は、セキュアシェルインターフェイス３２６及びウェブサービス１２２の各々と通信して、ユーザ１０２に資格情報を促すことなくテキストベースセキュアシェルセッションに対する認証を提供する能力を含む修正ＰＡＭモジュールであり得る。認証管理モジュール３２８は、ストレージデバイス１２０上のユーザ１０２又はシステム管理者などのシステム管理者が、新しいライブラリをインストールすることによって新しい認証方法を追加することを可能にする。ｐａｍ．ｃｏｎｆファイルなどの構成ファイルは、どの認証サービスを選択すべきかを判定する。典型的には、ウェブサービス１２２、セキュアシェルインターフェイス３２６、及び認証管理モジュール３２８は、ストレージデバイス１２０上のソフトウェアである。代替の実施形態では、これらの構成要素は、本明細書に記載された機能を実行するようにカスタム設計された回路機構に対応する。代替的に、構成要素は、ハードウェア及びソフトウェアの組み合わせに対応し得る。かかる全ての実施形態が可能であり、想到されている。

一連の工程に戻ると、工程１２において、ユーザ１０２は、テキストベースセキュアシェルセッションの要求を開始する。ユーザ１０２は、ユーザ名及びパスワードなどの資格情報を促されない。いくつかの実施形態では、ウェブベースアプリケーションユーザインターフェイス１１４は、ストレージデバイス１２０上でテキストベースセキュアシェルセッションを要求するためのボタンを有するＧＵＩである。要求を開始するための他の機構が可能であり、想到されている。ユーザ１０２がテキストベースセキュアシェル（ＳＳＨ）セッションに対してクライアントデバイス１１０上で要求を開始するとき、その要求は、ストレージデバイス１２０上でセキュアシェル（ＳＳＨ）プロセスに対するセキュア接続を確立するためのものであり、ＳＳＨプロセスは、ストレージデバイス１２０上でホストされるアプリケーション１２４に、セキュアかつ制限されたインターフェイスを提供する。

工程１３では、要求は、ストレージデバイス１２０に送信される。様々な実施形態では、要求は、ユーザ名、セキュアＨＴＴＰセッションのためのアクセストークン及び／又はオプションのリフレッシュトークン、並びにクライアントデバイスＩＤを含む。第三者アイデンティティプロバイダ１５０と通信するよりはむしろ、ストレージデバイス１２０は、テキストベースＳＳＨセッションの受信された要求における情報を、ストレージデバイス１２０上で記憶される情報と比較し得る。

上記の比較のために使用される情報は、少なくともユーザ名又は他のユーザ識別子、セキュアＨＴＴＰセッションに対して使用されるアクセストークン及び／又はオプションのリフレッシュトークン、並びにセキュアＨＴＴＰセッションに対して使用されるクライアントデバイスＩＤを含み得る。認証のために使用される比較は、ストレージデバイス１２０内で実行され得る。代替的に、ストレージデバイス１２０は、サーバ、別のストレージデバイス、又はストレージデバイス１２０に接続される他のコンピューティングデバイスに、比較操作の指標及び比較するための値を送信し得る。しかしながら、第三者アイデンティティプロバイダ１５０は、テキストベースＳＳＨセッションに対する認証のために使用されず、したがって比較を実行しない。ストレージデバイス１２０は、テキストベースＳＳＨセッションに対する要求に対処する最中に、第三者アイデンティティプロバイダ１５０と通信しない。いくつかの実施形態では、ストレージデバイス１２０上のアプリケーション１２４は、テキストベースセキュアシェル（ＳＳＨ）セッションに対する要求を受信して、工程１４において、認証モジュール３２８に要求を転送する。転送は、ＳＳＨインターフェイス３２６を通して行われ得る。

示される例では、工程１５において、認証管理モジュール３２８は、検証要求をウェブサービス１２２に送信する。検証要求は、少なくともユーザ名、セキュアＨＴＴＰセッションに対して使用されるアクセストークン及び／又はオプションのリフレッシュトークン、並びにセキュアＨＴＴＰセッションに対して使用されるクライアントデバイスＩＤを含み得、それらの各々は、クライアントデバイス１１０からの要求において送信された。検証要求はパスワードを含まず、ユーザ１０２は、テキストベースセキュアシェルセッションに対する要求を開始するとき、又はテキストベースセキュアシェルセッションを確立する工程の最中に、資格情報を促されなかった。

工程１６では、ウェブサービス１２２及び認証モジュール３２８は、要求されたテキストベースＳＳＨセッションに対してユーザ１０２を認証するために、図示されていないアイデンティティ及びアクセスマネージャ（ＩＡＭ）を使用する。前の工程１０に類似して、ストレージデバイス１２０は、受信されたユーザ名、クライアントデバイスＩＤ、並びにアクセストークン及び／又はオプションのリフレッシュトークンなどの複数の情報を使用して、アクセスチェックを実行する。前に説明したような他の情報は、また、アクセスチェックの最中に使用され得る。アクセスチェックは、少なくとも以前の比較操作を含み得る。ＨＴＴＰリダイレクションは、認可を実行するために使用されない。テキストベースセキュアシェルセッションに対する工程１３における要求が、以前に確立されたセキュアＨＴＴＰセッションなどの認証されたセッションに対する記憶された情報を既に含むので、ストレージデバイス１２０は、ＨＴＴＰリダイレクションを見合わせ得る。

いくつかの実施形態では、ストレージデバイス１２０が、受信された情報に基づいてユーザ１０２に対する成功した認可を判定するとき、ストレージデバイス１２０は、テキストベースセキュアシェル（ＳＳＨ）セッションに対する、対応するアクセストークン及びオプションのリフレッシュトークンを生成する。いくつかの実施形態では、これらのトークン値は、セキュアＨＴＴＰセッションに対して使用されるアクセストークン及びリフレッシュトークンと異なる場合がある。工程１７では、ウェブサービス１２２は、認証管理モジュール３２８に、成功した認可及び任意の新しいアクセストークンの通知を送信する。代替的に、ＩＡＭは、成功した認可の通知を認証モジュール３２８に送信する。工程１８及び１９では、成功した認可、任意の新しいアクセストークン、リフレッシュトークン、及び任意の他の新しいセッション識別子の通知が、クライアントデバイス１１０に送信される。

工程２０では、ユーザ１０２は、ユーザ１０２がユーザ名及びパスワードなどの資格情報を促されなかったが、認可されたユーザとしてテキストベースセキュアシェル（ＳＳＨ）セッションを取得する。ユーザ１０２は、ＣＬＩへのアクセスを有し得、かつコマンドを入力し、バッチジョブを送信し得る。

トークン管理セキュリティ戦略の生成及び維持は、複雑である。開発者は、トークン認証を支持及び維持するためのコードを書き込むことにかなりの時間を消費することよりもむしろ、ウェブベースアプリケーションを作成し、アプリケーションをオンラインにし、迅速に実行させることに時間を費やすことを好む。更に、多くの種類のタスク及び対応するウェブベースアプリケーションに対して、システム管理者は、テキストベースセキュアシェル（ＳＳＨ）セッションを使用することを好む。上に示されるように、ユーザ１０２は、資格情報を促されることなくテキストベースセキュアシェル（ＳＳＨ）セッションを取得することができる一方で、ストレージデバイス１２０は、第三者アイデンティティプロバイダ１５０を使用する。

ここで図４に戻ると、第三者ＳＳＯサービスを使用してウェブリソースをホストするリモートストレージデバイス上でセキュアＨＴＴＰセッションを効率的に確立するための方法４００の一実施形態が示される。考察のために、この実施形態における工程は、連続的な順序で示されている。しかしながら、一部の工程は、示されている順序とは異なる順序で行われ得、一部の工程は、同時に実行され得、一部の工程は、別の実施形態では存在しない場合がある。

ブロック４０２では、クライアントデバイスで作業する所与のユーザは、サービスデバイスとも称され得るリモートストレージデバイス上でウェブベースアプリケーションにアクセスすることを試みる。いくつかの実施形態では、ストレージデバイスは、ストレージアプライアンスである。他の実施形態では、ストレージデバイスは、バックアップサーバである。ストレージデバイスのためのＨＴＴＰセッション（ＨＴＴＰ）セッションは、所与のユーザのために要求される。所与のユーザは、所与のユーザ用の少なくともユーザ名及びパスワードなどの資格情報を促される。ブロック４０４では、ＨＴＴＰセッションに対する要求は、ウェブベースアプリケーションをホストするストレージデバイスに送信される。

ブロック４０６では、所与のユーザの認証のための別の位置が特定される。例えば、第三者アイデンティティプロバイダは特定され得、対応するＵＲＬは、その位置を判定するために使用され得る。ブロック４０８では、資格情報を用いる要求は、ストレージデバイスからアイデンティティプロバイダまでリダイレクトされる。様々な実施形態では、リダイレクションはＨＴＴＰリダイレクションである。

いくつかの実施形態では、最終的なアイデンティティプロバイダが所与のユーザに対する認証を実行すると分かる前に使用される２つ以上のリダイレクションがある。別のリダイレクション（条件付きブロック４１０）がある場合、方法４００の制御フローは、ブロック４０８に戻る。資格情報が、所与のユーザがＨＴＴＰセッション（条件付きブロック４１２）を通してウェブベースアプリケーションにアクセスすることを可能にする所与のユーザに対して有効であると判定される場合、ブロック４１４において、所与のユーザに関するユーザ役割、許可、及び他の情報が取得される。その情報は、アイデンティティプロバイダ内でディレクトリサービスから取得され得る。

ブロック４１６では、取得した情報と共にＨＴＴＰセッションを確立する成功した通知は、クライアントデバイスに戻される。更に、認可アサーションは、通知を用いて生成され、戻され得る。認可アサーションは、ユーザに関する成功した認可を示す１つ以上のトークン、キー、又は他の値を含み得る。資格情報が所与のユーザ（条件付きブロック４１２）に対して無効であると判定される場合、ブロック４１８において、認証が失敗したという通知は、生成され、クライアントデバイスに送信される。

ここで図５に戻ると、第三者ＳＳＯサービスを使用してセキュアＨＴＴＰセッションを確立した後にリモートストレージデバイス上でテキストベースセキュアシェルセッションを確立するための方法５００の一実施形態が示される。考察のために、この実施形態における工程は、連続的な順序で示されている。しかしながら、一部の工程は、示されている順序とは異なる順序で行われ得、一部の工程は同時に実行され得、一部の工程は別の実施形態では存在しない場合がある。

ブロック５０２では、資格情報の認証に関する通知は、クライアントデバイスにおいて受信される。所与のユーザは、ストレージアプライアンス又はストレージバックアップサーバとも称され得るストレージデバイスなどのサービスデバイスに、ＨＴＴＰセッションを獲得するための資格情報を送信した可能性がある。サービスデバイスは、サービスプロバイダとも称され得る。サービスデバイスは、クライアントデバイスに関してリモートに位置付けられ得る。サービスデバイスは、クライアントデバイスで作業をする所与のユーザによる使用のために、１つ以上のウェブベース又はクラウドベースアプリケーションをホストし得る。第三者アイデンティティプロバイダを使用して、所与のユーザを認可し得る。アイデンティティプロバイダは、所与のユーザの資格情報の認証に関する通知を送信した可能性がある。

第三者アイデンティティプロバイダにおける所与のユーザの認証が成功しなかった（条件付きブロック５０４）場合、ブロック５０６では、所与のユーザのためのログインは拒否され、他の資格情報が要求され得る。他の資格情報の拒否及び要求は、クライアントデバイスのモニタ上で提示さ得る。第三者アイデンティティプロバイダにおける所与のユーザの認証が成功した（条件付きブロック５０４）場合、ブロック５０８において、成功した認証の通知は、ＨＴＴＰセッションが要求されるサービスデバイスに送信される。第三者アイデンティティプロバイダからの認可アサーションも送信される。

サービスデバイスは、クライアントデバイスで作業をする所与のユーザによる使用のために、１つ以上のウェブベース又はクラウドベースアプリケーションをホストし得る。前に説明したように、第三者アイデンティティプロバイダにおける成功した認証の通知は、少なくとも、第三者アイデンティティプロバイダからのデジタル署名、並びに所与のユーザに関するユーザ役割、電子メールアドレス、及びアイデンティティ属性の他の証明を含む、１つ以上のユーザプロファイル属性を含む認可アサーションコンテンツ、並びに、アクセストークン及びオプションのリフレッシュトークン、又は他のキー値を含み得る。サービスデバイスは、この情報に対してアクセスチェックを実行して、受信されたコンテンツのソースを検証し、サービスデバイス上でホストされる１つ以上のウェブベース又はクラウドベースアプリケーションへのアクセスを要求する所与のユーザを検証する。

アクセスチェックを成功して完了するのと同時に、ブロック５１２において、サービスデバイスは、所与のユーザに関するログオンセキュリティコンテキストのローカルバージョン、並びに所与のユーザに関するローカルアクセストークン及びセッション識別子のうちの１つ以上を生成する。更に、サービスデバイスは、セッションクッキー、セッション識別子、インターネットプロトコル（ＩＰ）アドレス、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの１つ以上を含むクライアントデバイス識別子（ＩＤ）を生成し得る。サービスデバイスは、アクセストークン及び／又はリフレッシュトークン、並びにクライアントデバイス識別子を記憶し得る。記憶された情報を使用して、サービスデバイス上でホストされるウェブリソースに関してクライアントデバイスからのその後のアクセス要求を検査し得る。加えて、記憶された情報は、テキストベースセキュアシェルセッションを確立するためのその後の要求のために使用され得る。サービスデバイスは、クライアントデバイスに情報を送信する。この点において、所与のユーザは、ローカルクライアントデバイスにおいて、リモートサービスデバイスに「ログオンされる」と考えられる。ユーザは、リモートサービスデバイス上で確立されたセキュアＨＴＴＰセッションを有し、所与のユーザが認可された許可を有するサービスデバイス上でホストされる１つ以上のウェブベース及びクラウドベースアプリケーションにアクセスすることができる。

ブロック５１４では、テキストベースセキュアシェルセッションは、サービスデバイス及びクライアントデバイスＩＤからアクセストークンを使用して要求される。いくつかの実施形態では、所与のユーザは、テキストベースセキュアシェルセッションに対する要求を開始するために、ウェブベースアプリケーションユーザインターフェイス上でボタンを選択する。要求を開始するための他の機構が可能であり、想到されている。所与のユーザがテキストベースセキュアシェル（ＳＳＨ）セッションに対してクライアントデバイス上で要求を開始するとき、その要求は、サービスデバイス上でセキュアシェル（ＳＳＨ）プロセスに対するセキュア接続を確立するためのものであり、ＳＳＨプロセスは、サービスデバイス上でホストされるウェブベースアプリケーションに、セキュアかつ制限されたインターフェイスを提供する。所与のユーザは、要求の最中にユーザ名及びパスワードなどの資格情報を促されない場合がある。テキストベースセキュアシェルセッションの例としては、Ｗｉｎｄｏｗｓオペレーティングシステム上のＰｕＴＴＹ、及びＵｎｉｘ系オペレーティングシステム上のＳＳＨが挙げられる。

クライアントデバイス及びサービスデバイス上で動作するウェブブラウザ及びウェブサービスと異なり、テキストベースセキュアシェルインターフェイスは、第三者アイデンティティプロバイダによって実行されるＨＴＴＰリダイレクションに対処することができない。したがって、ブロック５１６では、サービスデバイスが、要求をアイデンティティプロバイダに送信するよりはむしろ、テキストベースセキュアシェルセッションを確立するために、要求を受信するとき、サービスデバイスは、所与のユーザのためにＨＴＴＰセッションを確立するために実行される初期の認可に基づいて、所与のユーザの認可に対処する。例えば、様々な実施形態では、サービスデバイス上のプラグ可能認証モジュール（ＰＡＭ）及びウェブサービスは、テキストベースセキュアシェルセッションを確立するための所与のユーザの認可に対処する。アイデンティティ及びアクセスマネージャ（ＩＡＭ）も使用され得る。

ＨＴＴＰセッションに対する前の検証に類似して、ウェブサービス又は他の制御論理（若しくは回路機構）は、テキストベースセキュアシェルセッションを確立するための要求を受信することに応答して、アクセスチェックを実行する。アクセスチェックは、所与のユーザ及び認可されたＨＴＴＰセッションに対応する複数の情報を使用する。それらの情報は、少なくとも所与のユーザに関するユーザ名、セキュアＨＴＴＰセッションに対して使用されるアクセストークン及びオプションのリフレッシュトークン、並びにセキュアＨＴＴＰセッションに対して使用されるクライアントデバイスＩＤを含み得る。前に説明したような他の情報は、また、アクセスチェックの最中に使用され得る。ＨＴＴＰリダイレクションは、テキストベースセキュアシェルセッションに対する認可を実行するために使用されない。

いくつかの実施形態では、サービスデバイスが、上記の情報に基づいて所与のユーザに対する成功した認可を判定するとき、サービスデバイスは、テキストベースセキュアシェルセッションに対する、対応するアクセストークンを生成する。様々な実施形態では、サービスデバイスは、受信されたアクセストークン及び／又はリフレッシュトークンを使用して、テキストベースセキュアシェルセッションに対するアクセストークンを生成する。他の実施形態では、テキストベースセキュアシェルセッションに対するアクセストークン又は別のセッション識別子は、多くの他の可能な仕方で生成され得る。サービスデバイスは、成功した認可及び任意の新しいアクセストークン又はセッション識別子の通知をクライアントデバイスに送信する。この点において、所与のユーザは、クライアントデバイスにおいて「ログオンされる」と考えられ、サービスデバイス上でテキストベースセキュアシェルセッションを有する。

ブロック５１８では、所与のユーザは、テキストベースセキュアシェルセッションのコマンドラインインターフェイス（ＣＬＩ）を通してサービスデバイス上でホストされる１つ以上の認可されたウェブベース及びクラウドベースアプリケーションにアクセスすることができる。これらのアクセスは、テキストベースセキュアシェルセッションに対して以前に生成されたアクセストークンを使用する。所与のユーザが資格情報を促されなかったが、所与のユーザは、次いで、認可されたユーザとして、ＧＵＩベースアプリケーションインターフェイスとは別個のウィンドウ内で（例えば、一実施形態では、ブラウザ内で）、テキストベースセキュアシェルセッションを開放し得る。所与のユーザは、コマンドを入力し得るか、バッチジョブを送信するなど効率的な自動操作シーケンスを実行し得る。

様々な実施形態では、本明細書に記載されている方法及び機構の１つ以上の部分が、クラウドコンピューティング環境の一部を形成し得る。かかる実施形態では、リソースは、１つ以上の様々なモデルによるサービスとして、インターネットを介して提供され得る。かかるモデルとしては、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）、Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（Ｐａａｓ）、及びＳｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）が挙げられ得る。ＩａａＳでは、コンピュータインフラストラクチャがサービスとして提供される。かかる事例では、コンピューティング機器は概してサービスプロバイダが所有し、操作する。ＰａａＳモデルでは、開発者がソフトウェアソリューションを開発するために使用するソフトウェアツール及び基礎となる機器が、サービスとして提供され、サービスプロバイダによってホストされ得る。ＳａａＳは典型的に、オンデマンドのサービスとしての、サービスプロバイダがライセンス発行するソフトウェアを含む。サービスプロバイダは、ソフトウェアをホストする場合も、ソフトウェアを所与の期間、顧客に配置する場合もある。上記のモデルの多様な組み合わせが可能であり、想到されている。

上記の実施形態についてかなり詳細に説明してきたが、上記の開示内容を十分理解すれば、多数の変形及び修正が当業者には明らかになるであろう。以下の特許請求の範囲は、かかる全ての変形及び修正を抱持するように解釈されることが意図されている。

Claims (20)

1. 認証システムであって、
   一連の１つ以上のハイパーテキスト転送プロトコル（ＨＴＴＰ）リダイレクションを通して複数のユーザを認証するように構成されている第三者アイデンティティプロバイダ（ＩＤＰ）と、
   アプリケーションをホストするストレージデバイスと、
   クライアントデバイスであって、
   前記アプリケーションにアクセスするために、前記ストレージデバイスと、セキュアＨＴＴＰセッション及びセキュアシェル（ＳＳＨ）セッションの両方を確立するための要求を送信することと、
   ＳＳＨセッションを確立する所与の要求を送信することであって、前記要求が、前記第三者ＩＤＰを使用して以前に確立されたセキュアＨＴＴＰセッションに対応する少なくとも第１のアクセストークンを含む、送信することと、を行うように構成されているクライアントデバイスと、を備え、
   前記所与の要求を受信することに応答して、前記ストレージデバイスは、前記第１のアクセストークンが前記以前に確立されたセキュアＨＴＴＰセッションに対応することを検証することに更に応答して、前記所与の要求がパスワードを欠くが、前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可する、認証システム。
2. 前記ストレージデバイスが、セキュアＨＴＴＰセッションを通して前記アプリケーションにアクセスすることを要求する前記クライアントデバイス上で、前記複数のユーザのうちの所与のユーザに対する成功した認証の指標を前記第三者ＩＤＰから受信することに応答して、前記クライアントデバイスに、少なくとも前記第１のアクセストークン及びクライアントデバイス識別子（ＩＤ）を送信するように更に構成されている、請求項１に記載の認証システム。
3. 前記ストレージデバイスが、前記第１のアクセストークン及び前記クライアントデバイスＩＤの各々を記憶して、前記セキュアＨＴＴＰセッションを介して前記クライアントデバイスからの前記アプリケーションのその後のアクセスを検証するために使用するように更に構成されている、請求項２に記載の認証システム。
4. 前記クライアントデバイスＩＤが、セッションクッキー、インターネットプロトコル（ＩＰ）アドレス、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの１つ以上を含む、請求項３に記載の認証システム。
5. 前記ＳＳＨセッションを確立する前記クライアントデバイスからの前記所与の要求が、前記クライアントデバイスＩＤを更に含む、請求項２に記載の認証システム。
6. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記ストレージデバイスは、前記要求における少なくとも前記第１のアクセストークン及び前記クライアントデバイスＩＤが、前記記憶された第１のアクセストークン及び前記記憶されたクライアントデバイスＩＤに整合するかどうかを判定するように更に構成されている、請求項３に記載の認証システム。
7. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記ストレージデバイスが、いかなるＨＴＴＰリダイレクションも見合わせるように更に構成されている、請求項３に記載の認証システム。
8. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記ストレージデバイスが、前記第三者ＩＤＰの使用を見合わせるように更に構成されている、請求項３に記載の認証システム。
9. プロセッサで実行するための方法であって、
   第三者アイデンティティプロバイダ（ＩＤＰ）を用いて、一連の１つ以上のハイパーテキスト転送プロトコル（ＨＴＴＰ）リダイレクションを通して複数のユーザを認証することと、
   ストレージデバイス上でアプリケーションをホストすることと、
   前記アプリケーションにアクセスするために、前記ストレージデバイスと、セキュアＨＴＴＰセッション及びセキュアシェル（ＳＳＨ）セッションの両方を確立するために、要求をクライアントデバイスから送信することと、
   ＳＳＨセッションを確立するために、所与の要求を前記クライアントデバイスから前記ストレージデバイスに送信することであって、前記所与の要求が、前記第三者ＩＤＰを使用して以前に確立されたセキュアＨＴＴＰセッションに対応する少なくとも第１のアクセストークンを含む、送信することと、
   前記第１のアクセストークンが前記以前に確立されたセキュアＨＴＴＰセッションに対応することを検証することに応答して、前記所与の要求がパスワードを欠くが、前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可することと、を含む、方法。
10. セキュアＨＴＴＰセッションを通して前記アプリケーションにアクセスすることを要求する前記クライアントデバイス上で、前記複数のユーザのうちの所与のユーザに対する成功した認証の指標を前記第三者ＩＤＰから受信することに応答して、前記クライアントデバイスに、少なくとも前記第１のアクセストークン及びクライアントデバイス識別子（ＩＤ）を送信することを更に含む、請求項９に記載の方法。
11. 前記第１のアクセストークン及び前記クライアントデバイスＩＤの各々を前記ストレージデバイス内に記憶して、前記セキュアＨＴＴＰセッションを介して前記クライアントデバイスからの前記アプリケーションのその後のアクセスを検証するために使用することを更に含む、請求項１０に記載の方法。
12. 前記クライアントデバイスＩＤが、セッションクッキー、インターネットプロトコル（ＩＰ）アドレス、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの１つ以上を含む、請求項１１に記載の方法。
13. 前記ＳＳＨセッションを確立するための前記クライアントデバイスからの前記所与の要求が、前記クライアントデバイスＩＤを更に含む、請求項１０に記載の方法。
14. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記方法は、前記要求における少なくとも前記第１のアクセストークン及び前記クライアントデバイスＩＤが、前記記憶された第１のアクセストークン及び前記記憶されたクライアントデバイスＩＤに整合するかどうかを判定することを更に含む、請求項１１に記載の方法。
15. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記方法が、いかなるＨＴＴＰリダイレクションも見合わせることを更に含む、請求項１１に記載の方法。
16. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記方法が、前記第三者ＩＤＰの使用を見合わせることを更に含む、請求項１１に記載の方法。
17. ストレージデバイスであって、
    プロセッサと、
    メモリであって、
    アプリケーションを記憶することと、
    プログラム命令を記憶することであって、
    一連の１つ以上のハイパーテキスト転送プロトコル（ＨＴＴＰ）リダイレクションを通して、複数のユーザを認証するように構成されている、第三者アイデンティティプロバイダ（ＩＤＰ）に要求を送信すること、
    セキュアシェル（ＳＳＨ）セッションを確立するために、所与の要求をクライアントデバイスから受信することであって、前記所与の要求が、前記第三者ＩＤＰを使用して前記クライアントデバイスのために以前に確立されたセキュアＨＴＴＰセッションに対応する少なくとも第１のアクセストークンを含む、受信すること、及び
    前記第１のアクセストークンが前記以前に確立されたセキュアＨＴＴＰセッションに対応することを検証することに更に応答して、前記所与の要求がパスワードを欠くが、前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可すること、を行うように、前記プロセッサによって実行可能なプログラム命令を記憶することと、を行うように構成されているメモリと、を備える、ストレージデバイス。
18. 前記プログラム命令が、セキュアＨＴＴＰセッションを通して前記アプリケーションにアクセスすることを要求する前記クライアントデバイス上で、前記複数のユーザのうちの所与のユーザに対する成功した認証の指標を前記第三者ＩＤＰから受信することに応答して、前記クライアントデバイスに、少なくとも前記第１のアクセストークン及びクライアントデバイス識別子（ＩＤ）を送信するように前記プロセッサによって更に実行可能である、請求項１７に記載のストレージデバイス。
19. 前記ＳＳＨセッションを確立するための前記クライアントデバイスからの前記所与の要求が、前記クライアントデバイスＩＤを更に含む、請求項１８に記載のストレージデバイス。
20. 前記クライアントデバイスに前記ＳＳＨセッションを確立することを認可するために、前記プログラム命令は、前記要求における少なくとも前記第１のアクセストークン及び前記クライアントデバイスＩＤが、前記第１のアクセストークン及び前記記憶されたクライアントデバイスＩＤの記憶された値に整合するかどうかを判定するように更に実行可能である、請求項１８に記載のストレージデバイス。
    

Images