0

クラウドにアクセスするには、既存の saml フレームワークを openstack と統合する必要があります。私はこのプロジェクトのまさに始まりにいます。openstack をインストールし、いくつかのドキュメントを読みました。そのアーキテクチャにより、keystone はカスタム フレームワークを処理できると読みましたが、少し迷っています。始めるのに助けが必要なのですが、何を探すべきですか? 私が開始するために見ることができるドキュメントまたはインスピレーションプロジェクトへのリンクはありますか?

より詳細に言い換える：

独自のログイン ページで動作する、FC と呼ばれるフェデレーション ID プロバイダーがあります。これは標準のユースケースです:

  • 保護されたページは、ユーザーを FC のログイン ページにリダイレクトします。
  • ユーザーは名前とパスワードを挿入し、フォームを送信します
  • ログインページは名前とパスワードをアイデンティティサーバーに送信し、資格情報を要求します
  • サーバーは資格情報を提供します
  • ユーザーは最初の (これ以上) 保護されていないページにリダイレクトされます
    • この場合の保護されたページは、OpenStack のダッシュボードです。

@Heckj の回答を読んで、名前とパスワードを FC ログイン ページに送信し、その回答を処理する keystone の ID バックエンドを作成する必要がありますか?

4

1 に答える 1

1

OpenStack の Folsom リリースの時点で、ID メカニズムと API はフェデレーションの概念をサポートしていません。これは、OpenStack Grizzly デザイン サミットで議論されるトピックの 1 つです。その議論/会話の詳細については、ブループリント フォー フェデレーションで確認できます。

OpenStack の Essex および Folsom リリースの場合、ID サービス ( Keystone ) には、Driver ( https://github.com/openstack/keystone/blob/master/keystone内) からサブクラス化して実装することにより、ID「プラグイン」を作成するメカニズムがあります。 /identity/core.py )。この例は、プロジェクトで提供されるバックエンド ( https://github.com/openstack/keystone/tree/master/keystone/identity/backends )にあります。

申し訳ありませんが、カスタム ID バックエンドの作成に関する特定のドキュメントと例はありませんが、既に作成されています。

DeLac の拡張用にこれを少し拡張します。

Keystone は、基本認証よりも詳細な OpenStack 固有の一連の情報を提供します。最も具体的には、プロジェクトまたはテナントの概念と、ユーザーがそのプロジェクトまたはテナントに対して承認されているかどうかが含まれます。keystone が他の OpenStack プロジェクトで使用されるトークン資格情報を提供する場合、それらのプロジェクトは Keystone にクエリを返し、これらの追加の詳細を決定して、承認ポリシーを適用することができます。

Keystone をサポートする別の認証メカニズム (フェデレーション ID プロバイダーなど) をプラグインする場合は、Folsom リリースの時点で、特定のプロバイダーに対して認証できる Keystone ID バックエンドを作成することで行います。ユーザーに関する情報、ユーザーがプロジェクトにどのように関連付けられているか、およびユーザーが各プロジェクトに対して持つロールについての情報を提供するのに適切と思われるロジック。

すべての keystone を変更して、SAML またはこのスキームの他のバリエーションを使用することができますが、その場合、認証のプラグイン アップグレードだけでなく、多くのコンポーネントを完全に置き換えることになります。これをもう少し簡単にするための取り組みが進行中です (特に、単純なトークンの代わりに PKI ベースの認証を有効にする) が、そのような方法で重要なことは、かなりの作業になります。とはいえ、Keystone やその他の OpenStack コンポーネントは、使用している API とインターフェイスが適切に定義されているため、不可能な作業ではありません。

于 2012-10-01T21:57:58.730 に答える