Node.jsに基づくSSOテクノロジーの実装

Webアプリケーションは、通信プロトコルとしてHTTPを使用するクライアントサーバーアーキテクチャを使用して作成されます。 HTTPはステートレスプロトコルです。ブラウザがサーバーにリクエストを送信するたびに、サーバーはそのリクエストを他のリクエストとは独立して処理し、同じブラウザからの前または後のリクエストに関連付けません。これは、とりわけ、誰もがいかなる方法でも保護されていないサーバーリソースにアクセスできることを意味します。一部のサーバーリソースを部外者から保護する必要がある場合、これは、ブラウザーがサーバーに要求できるものを何らかの方法で制限する必要があることを意味します。つまり、要求を認証し、テストに合格したものだけに応答し、テストに合格しなかったものは無視する必要があります。リクエストを認証するには、リクエストに関する情報が必要です。ブラウザ側に保存されます。 HTTPプロトコルは要求の状態を保存しないため、サーバーとブラウザーが接続の状態を共同で管理できるようにするための追加のメカニズムが必要です。これらのメカニズムには、Cookie、セッション、JWTの使用が含まれます。







単一のWebプロジェクトについて話している場合、クライアントとサーバー間の特定の対話セッションの状態に関する情報は、ユーザーがシステムにログインするときにユーザー認証を使用して簡単に維持できます。しかし、そのような独立したシステムが進化して複数のシステムに変わると、開発者はこれらの個別のシステムのそれぞれの状態に関する情報を維持するという問題に直面します。実際には、この質問は次のようになります。「これらのシステムのユーザーは、それぞれを個別に入力し、終了する必要がありますか？」



時間の経過とともに複雑さが増すシステムと、それらのシステムがユーザーとどのように対話するかについては、1つの良いルールがあります。つまり、プロジェクトアーキテクチャの複雑さに関連する問題を解決する負担は、ユーザーではなくシステムにあります。 Webプロジェクトの内部メカニズムがどれほど複雑であるかは問題ではありません。ユーザーには統一されたシステムのように見えるはずです。つまり、多くのコンポーネントで構成されるWebシステムを使用しているユーザーは、1つのシステムを使用しているかのように何が起こっているかを認識する必要があります。特に、SSO（シングルサインオン）（シングルサインオンテクノロジ）を使用したこのようなシステムでの認証について説明しています。



SSOを使用するシステムを作成するにはどうすればよいですか？ここで古き良きCookieベースのソリューションを考えるかもしれませんが、このソリューションには制限があります。制限は、Cookieのインストール元のドメインに適用されます。これは、Webアプリケーションのすべてのサブシステムのすべてのドメイン名を1つのトップレベルドメインに収集することによってのみ回避できます。



今日の環境では、このようなソリューションは、マイクロサービスアーキテクチャの広範な採用によって妨げられています。 Webプロジェクトの開発にさまざまなテクノロジーが使用され、さまざまなサービスがさまざまなドメインでホストされることがあると、セッション管理はより複雑になりました。さらに、以前はJavaで作成されていたWebサービスが、Node.jsプラットフォームの機能を使用して作成を開始しました。これにより、Cookieの操作が難しくなりました。現在、セッションの管理はそれほど簡単ではないことが判明しました。



これらの困難は、システムにログインする新しい方法の開発につながりました。特に、シングルサインオンのテクノロジーについて話しています。

シングルサインオンテクノロジー

シングルサインオンテクノロジーの基本原則は、ユーザーが多数のシステムで構成されるプロジェクトの1つのシステムにログインし、他のすべてのシステムで再度ログインしなくても承認できることです。同時に、すべてのシステムからの集中型出口について話し合っています。



教育目的で、Node.jsプラットフォームにSSOテクノロジーを実装します。



このテクノロジーを企業規模で実装するには、トレーニングシステムの開発に費やすよりもはるかに多くの労力が必要になることに注意してください。そのため、大規模プロジェクト向けに設計された特殊なSSOソリューションがあります。

SSOログインはどのように構成されていますか？

SSO実装の中心は、ユーザーを認証するための情報を受け入れることができる単一の独立した認証サーバーです。例-メールアドレス、ユーザー名、パスワード。他のシステムは、それらにログインするための直接的なメカニズムをユーザーに提供しません。それらは、認証サーバーからユーザーに関する情報を受信することにより、間接的にユーザーを承認します。間接認証メカニズムは、トークンを使用して実装されます。



これがsimple-ssoプロジェクトのコードリポジトリであり、その実装についてはここで説明します。Node.jsフレームワークを使用していますが、別のものを使用して同じものを実装できます。システムを操作するユーザーのアクションと、このシステムを構成するメカニズムを段階的に分析してみましょう。

ステップ1

ユーザーがシステム上の保護されたリソースにアクセスしようとします（このリソースを「SSOコンシューマー」、「sso-consumer」と呼びましょう）。SSOコンシューマーは、ユーザーがログインしていないことを検出し、自分のアドレスをクエリパラメーターとして使用して、ユーザーを「SSOサーバー」（「sso-server」）にリダイレクトします。正常に認証されたユーザーは、このアドレスにリダイレクトされます。このメカニズムは、Expressミドルウェアによって提供されます。

const isAuthenticated = (req, res, next) => {
  //   ,   ,
  //     -     SSO-     
  //    URL  URL,     
  // ,   
  const redirectURL = `${req.protocol}://${req.headers.host}${req.path}`;
  if (req.session.user == null) {
    return res.redirect(
      `http://sso.ankuranand.com:3010/simplesso/login?serviceURL=${redirectURL}`
    );
  }
  next();
};

module.exports = isAuthenticated;

ステップ2

SSOサーバーは、ユーザーがログインしていないことを検出し、ユーザーをログインページにリダイレクトします。

const login = (req, res, next) => {
  //  req.query  url,      
  //    ,     sso-.
  //        
  //     
  const { serviceURL } = req.query;
  //         URL.
  if (serviceURL != null) {
    const url = new URL(serviceURL);
    if (alloweOrigin[url.origin] !== true) {
      return res
        .status(400)
        .json({ message: "Your are not allowed to access the sso-server" });
    }
  }
  if (req.session.user != null && serviceURL == null) {
    return res.redirect("/");
  }
  //          -  
  //   
  if (req.session.user != null && serviceURL != null) {
    const url = new URL(serviceURL);
    const intrmid = encodedId();
    storeApplicationInCache(url.origin, req.session.user, intrmid);
    return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);
  }

  return res.render("login", {
    title: "SSO-Server | Login"
  });
};

ここでセキュリティについてコメントします。SSOサーバーへの要求パラメーターの形式で



チェックしserviceURLます。これにより、このURLがシステムに登録されているかどうか、およびこのURLが表すサービスがSSOサーバーのサービスを使用できるかどうかを確認できます。



SSOサーバーの使用が許可されているサービスのURLのリストは次のようになります。

const alloweOrigin = {
"http://consumer.ankuranand.in:3020": true,
"http://consumertwo.ankuranand.in:3030": true,
"http://test.tangledvibes.com:3080": true,
"http://blog.tangledvibes.com:3080": fasle,
};

ステップ3

ユーザーは、ログイン要求でSSOサーバーに送信されるユーザー名とパスワードを入力します。





ログインページ

ステップ4

SSO認証サーバーは、ユーザーの情報を検証し、それ自体とユーザーの間にセッションを作成します。これがいわゆる「グローバルセッション」です。承認トークンはすぐに作成されます。トークンはランダムな文字の文字列です。この文字列がどの程度正確に生成されるかは重要ではありません。重要なことは、同じような行が異なるユーザーに対して繰り返されないこと、そしてそのような行は偽造するのが難しいということです。

ステップ5

SSOサーバーは、認証トークンを取得して、新しくログインしたユーザーの送信元に渡します（つまり、トークンをSSOコンシューマーに渡します）。

const doLogin = (req, res, next) => {
  //         .
  //         , 
  // userDB -   ,   ,   
  const { email, password } = req.body;
  if (!(userDB[email] && password === userDB[email].password)) {
    return res.status(404).json({ message: "Invalid email and password" });
  }

  //     
  const { serviceURL } = req.query;
  const id = encodedId();
  req.session.user = id;
  sessionUser[id] = email;
  if (serviceURL == null) {
    return res.redirect("/");
  }
  const url = new URL(serviceURL);
  const intrmid = encodedId();
  storeApplicationInCache(url.origin, id, intrmid);
  return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);
};

繰り返しますが、いくつかのセキュリティ上の注意：

• このトークンは常に中間メカニズムと見なす必要があり、別のトークンを取得するために使用されます。
• JWTを中間トークンとして使用している場合は、その中にシークレットを含めないようにしてください。

ステップ6

SSOコンシューマーはトークンを受け取り、SSOサーバーに接続してトークンを確認します。サーバーはトークンをチェックし、ユーザー情報を含む別のトークンを返します。このトークンは、SSOコンシューマーがユーザーとのセッションを作成するために使用します。このセッションはローカルと呼ばれます。



ExpressベースのSSOコンシューマーで使用されるミドルウェアコードは次のとおりです。

const ssoRedirect = () => {
  return async function(req, res, next) {
    // ,    req queryParameter,  ssoToken,
    //  ,    .
    const { ssoToken } = req.query;
    if (ssoToken != null) {
      //   ssoToken   ,  .
      const redirectURL = url.parse(req.url).pathname;
      try {
        const response = await axios.get(
          `${ssoServerJWTURL}?ssoToken=${ssoToken}`,
          {
            headers: {
              Authorization: "Bearer l1Q7zkOL59cRqWBkQ12ZiGVW2DBL"
            }
          }
        );
        const { token } = response.data;
        const decoded = await verifyJwtToken(token);
        //      jwt,  
        // global-session-id  id ,  
        //         .
        req.session.user = decoded;
      } catch (err) {
        return next(err);
      }

      return res.redirect(`${redirectURL}`);
    }

    return next();
  };
};

SSOコンシューマーから要求を受信した後、サーバーはトークンの存在と有効期限を確認します。検証されたトークンは有効と見なされます。



この場合、SSOサーバーは、トークンの検証に成功した後、ユーザーに関する情報を含む署名済みJWTを返します。

const verifySsoToken = async (req, res, next) => {
  const appToken = appTokenFromRequest(req);
  const { ssoToken } = req.query;
  //        ssoToken .
  //  ssoToken    - ,   .
  if (
    appToken == null ||
    ssoToken == null ||
    intrmTokenCache[ssoToken] == null
  ) {
    return res.status(400).json({ message: "badRequest" });
  }

  //  appToken  -     
  const appName = intrmTokenCache[ssoToken][1];
  const globalSessionToken = intrmTokenCache[ssoToken][0];
  //  appToken   ,   SSO-        
  if (
    appToken !== appTokenDB[appName] ||
    sessionApp[globalSessionToken][appName] !== true
  ) {
    return res.status(403).json({ message: "Unauthorized" });
  }
  // ,     
  const payload = generatePayload(ssoToken);

  const token = await genJwtToken(payload);
  //    ,     
  delete intrmTokenCache[ssoToken];
  return res.status(200).json({ token });
};

ここにいくつかの安全上の注意があります。

• このサーバーを認証に使用するすべてのアプリケーションは、SSOサーバーに登録する必要があります。サーバーにリクエストを送信するときに確認するために使用されるコードを割り当てる必要があります。これにより、SSOサーバーとSSOコンシューマー間の相互作用を整理するときに、より高いレベルのセキュリティを実現できます。
• アプリケーションごとに異なる「プライベート」および「パブリック」rsaファイルを生成し、それぞれがそれぞれのパブリックキーを使用して社内でJWTを検証できるようにすることができます。

さらに、アプリケーションレベルのセキュリティポリシーを定義し、その集中ストレージを整理できます。

const userDB = {
  "info@ankuranand.com": {
    password: "test",
    userId: encodedId(), //   ,         .
    appPolicy: {
      sso_consumer: { role: "admin", shareEmail: true },
      simple_sso_consumer: { role: "user", shareEmail: false }
    }
  }
};

ユーザーがシステムに正常にログインすると、ユーザーとSSOサーバー間、およびユーザーと各サブシステム間でセッションが作成されます。ユーザーとSSOサーバー間で確立されたセッションは、グローバルセッションと呼ばれます。ユーザーと、ユーザーにサービスを提供するサブシステムとの間に確立されたセッションは、ローカルセッションと呼ばれます。ローカルセッションが確立されると、ユーザーは外部リソースに閉じられたサブシステムリソースを操作できるようになります。





ローカルおよびグローバルセッションの設定

SSOコンシューマーとSSOサーバーのクイックツアー

SSOコンシューマーとSSOサーバーの機能について簡単に説明します。

▍SSOコンシューマー

1. SSOコンシューマサブシステムは、ユーザーをSSOサーバーにリダイレクトすることによってユーザーを認証しません。
2. このサブシステムは、SSOサーバーから渡されたトークンを受け取ります。
3. サーバーと対話して、トークンの有効性を検証します。
4. 彼女はJWTを受け取り、公開鍵を使用してこのトークンを検証します。
5. このサブシステムはローカルセッションを確立します。

▍SSOサーバー

1. SSOサーバーはユーザーのログイン情報を検証します。
2. サーバーはグローバルセッションを作成します。
3. 承認トークンを作成します。
4. 承認トークンがSSOコンシューマーに送信されます。
5. サーバーは、SSOコンシューマーから渡されたトークンの有効性を検証します。
6. サーバーは、ユーザー情報とともにSSOJWTをコンシューマーに送信します。

一元化されたログアウトの構成

SSOの実装方法と同様に、SSOテクノロジーを実装できます。ここでは、次の考慮事項を考慮する必要があります。

1. ローカルセッションが存在する場合は、グローバルセッションも存在する必要があります。
2. グローバルセッションが存在する場合、必ずしもローカルセッションが存在することを意味するわけではありません。
3. ローカルセッションが破棄された場合、グローバルセッションも破棄する必要があります。

結果

その結果、システムに統合できるシングルサインオンテクノロジの既成の実装が多数あることに注意してください。それらはすべて、独自の長所と短所があります。このようなシステムを最初から独立して開発することは、各システムの特性を分析する必要がある反復プロセスです。これには、ログイン方法、ユーザー情報の保存、データの同期などが含まれます。



プロジェクトはSSOメカニズムを使用していますか？