web-dev-qa-db-ja.com

ローカルのWeb開発環境を中央のSSOソリューションと統合するにはどうすればよいですか？

単一ページのWebアプリケーションがあり、OAuth2を使用する新しいSSOサイト（これも私たちのサイトです）があり、それらを接続しようとしています。

実稼働/ステージング/ CIデプロイメントでは、すべてを簡単に接続できます。例えば：

  • 本番環境では、_https://app.company.com_を使用して、prodバックエンドポイントに__https://sso.company.com_へのアクセス権を付与します。
  • cIでは、_https://app.ci.company.com_で開発バックエンドにアクセスし、認証のために_https://sso.ci.company.com_をポイントします。

アプリで開発を行っているときは、_http://localhost:8000/_のような場所でローカルにアクセスし、共有開発バックエンドをポイントします。過去には、開発バックエンドに対して独自の認証を行うだけでした（エンドユーザーの資格情報を取得して送信する）が、SSOを使用して認証を行うようにしたいと考えています。

ローカルで開発したいすべての開発者が独自のSSOサービスをセットアップしてカスタム構成する必要なく、これをどのように行うことができるかという問題が浮上します。具体的には、共有dev/CI SSOを使用して、ローカル展開をポイントできますか？

検討した内容：

  • プロキシファイル/ホストファイルを使用し、http(s)://sso.ci.company.comがhttp(s)://localhost:8000を指すようにします。これにより、ローカルでHTTPSを設定したり、SSOで非HTTPS URLに直接アクセスしたりする必要があります。また、セットアップは少し面倒です。
  • ローカルアプリが自身を識別する引数を使用してSSOにリダイレクトし、SSOがそれを使用してリダイレクト先を認識できるようにします。たとえば、_https://sso.ci.company.com/?appUrl=localhost:8000_にリダイレクトします。これにより、本番環境ではオフにする必要があるSSOのオープンエンドリダイレクトを強制することになります。これは少し「奇妙」ですが、機能し、アプリにブラックボックス化できます。
  • すべての開発ボックスでローカルにSSOを実行するだけです。 「すべてを実行できる1つのボックス」スクリプトに到達するには多くの設定が必要になるため、これは基本的に非解決策であり、基本的に必要なのはチェックするだけなので、現時点で私たちの価値ある利点の1つを無効にします。任意のシステムでコードを実行して実行します。私はこれが一般的に以前に行われたのを見てきました（多くの場合、開発VMの上で）。私たちがより近い可能性のあるオプションを探りたいと思います。

この種の問題や、まだ検討していないアイデアの側面に対する解決策はありますか？

web-developmentdevelopment-environmentsso
6
Steven

以前は、SSOとローカルの開発者環境がある環境で働いていました。

SSOおよび開発者環境で作業する必要がある主な問題は、ローカル開発環境にアクセスするときにドメインCookieを取得できる必要があることです。

確かに、これの一部は環境のセットアップ方法に関係しています（そして、私がこれに関与したのは何年も前のことです）。これは、静的html、古いPerl cgis、Java EEのweblogicサーバー、aspで実行する必要がある一部のアプリのiisサーバー、エンジニアリングが実行するもの）が混在するポリグロット環境でした。 。SSOがこの情報を伝達する方法は、リバースプロキシがhttpヘッダーに認証されたユーザー名とそれに関連付けられたすべてのアクセス権を突き刺していたことです。この方法では、誰が取得したかに関係なく、ヘッダーを確認してそこから続行できます。

最初に、各開発者が「dev.company.com」ドメインのホスト名を持つようにDNSが設定されました-したがって、「sxu.dev.company.com」（あなたにとって）と「jsmith.dev.comapny.com」ジョン・スミス。これらすべての名前（CNAMES）は、単一の一般的なdevリバースプロキシ（リバースプロキシにはほとんど影響がなかった）をポイントし、そこから着信する仮想ホスト名を調べて、適切な開発者のマシンにリクエストを転送しました。 SSOコードとの対話はリバースプロキシ内に完全に含まれているため、他の場所に追加のライブラリをインストールする必要はありません。

インフラストラクチャとの相互作用は、新しい採用者がいるたびにcommon.dev.company.comに別のcnameを追加することでした。次に、その名前をいくつかのm4マクロで実行されたファイルに追加して、適切なApache http.confを生成しました。リバースプロキシ用のファイル（多少の作業が必要最初時間）.

このアイデアが整ったら、httpを介してすべてを適切な開発者のマシンに転送するように機能するリバースプロキシの設定を検討することをお勧めします（受信した接続の種類に関係なく）。 https://sxu.ci.company.com/xyzは、httpsを処理するリバースプロキシに移動し、http://10.1.2.3/xyzの開発ボックスに転送します。このアプローチの注意点は、コードに絶対パスがある場合、または開発者のサーバーが、インストールされている場所と同じ形式のリンクを生成するために使用されているプロトコルを認識しようとする場合です。物事は少し不安定になるかもしれません（これは専門用語です）。

これにより、httpsをローカルで設定する（1つのサーバーのみがhttpsを実行している）、またはssoサーバーを非httpsのURLに移動するように変更する問題が回避されます。別の場所で別のセットアップを使用しています。

あなたのローカル開発ボックスがアクセスに応答するかどうかはわかりません以外 localhost（その有効な構成）、もしそうなら、リクエストはプロキシではなくこのケースからのものなので、変更する必要がありますローカルブラウザ。

私は他の開発者が環境に影響を与える可能性があることを意味するという副次的な利点を指摘したいと思います（リポジトリの方法がわからないログファイルを監視しているときに誰かにバグを再現してもらいたい-彼らにサーバ）。

2番目のオプションは非標準的ではないアプローチです（appUrlタイプのパラメーターの制限されたセットを許可するように構成されているいくつかの本番SSOシステムを思い出します-部分的には、外部の人がSSOを使用してログイン後に特定のページに移動できるようにするためです。 'dev-> localhost：8000'のマッピングを追加すると、これが可能になりますただし localhostの問題に対処する方法を再検討する必要があります。company.comCookieが取得されません。ローカルボックスを変更して、localhost.company.comとして識別する必要があります。

3
user40980