3

ユーザーを認証するためのSSOシステムがあります。

これらの 2 つのオプションの間で議論があります。

  1. 各アプリケーションの承認を 1 つのデータベース (または他の単一のソリューション) に集中させ、SSO 要求内の情報を取得する必要がありますか?

  2. 各 Web アプリケーション クライアントは、ローカル データベース/スキームで独自の承認ロジックを管理する必要があります。

4

2 に答える 2

4

認証、ロギング、そしてもちろん承認などの非機能要件からビジネス ロジックを分離するように努める必要があります。

すでに SSO を実装しており、SSO がユーザー ID を格納するためのバックエンドとしてユーザー ディレクトリを使用していることは間違いありません。これは、保護するアプリケーションから認証を正常に外部化したことを示しています。アプリごとにユーザー名とパスワードのデータベースを用意することを検討したことがありますか? パスワードやハッシュなどを管理するロジックを書くことを考えたことはありますか? もちろん違います！同じことが認可にも当てはまります。

アナリスト企業である Gartner は、検討している領域をExternalized Authorization Managementと定義しています。Gartner の顧客である場合は、ここで詳細を確認できます。

外部化された承認を実現するには、主に 2 つのモデルがあります。役割ベースのアクセス制御モデル (RBAC) を使用するか、属性ベースのアクセス制御 (ABAC) を目指します。NIST は、両方の定義などを提供しています。

多くのアプリケーション フレームワークは、何らかの形式の外部化を提供します。Java Spring を例にとると、Spring Security と Access Decision Manager が付属しています (Spring アーキテクチャの詳細については、こちら)。PHP、Ruby、Python、および .NET の名前を挙げることができますが、いくつかはすべて独自の方法を持っています。

したがって、可能であれば、アプリ内に承認ロジックを実装するのではなく、提供されているフレームワークを活用してください。

さらに進んで、外部化された承認を標準化することを検討することもできます。SSO に標準 (SAML) があるように、外部化された承認には XACML ( eXtensible Access Control Markup Language ) があります。これは、SAML によく似た OASIS によって定義された標準であり、IBM、Oracle、Axiomatics などによってサポートされています。

XACML は、外部化されたきめの細かい承認に対するポリシーベースのアプローチを提供します。ポリシーを記述して、任意の数のアプリケーションに適用できます。もちろん、XACML を使用して SSO レイヤーを拡張することもできます。

外部化された認証を使用する利点 (特に XACML で標準化されている利点) は次のとおりです。

  • 承認ロジックの統合: 保守がより簡単で安価になります
  • セキュリティの向上: XACML は表現力が向上し、セキュリティが正しく実装されているかどうかを確認する場所が 1 か所になりました。
  • 新しいビジネスを公開する能力: 私が扱っている一部の顧客は、アプリを Web やサード パーティに公開したいと考えています。きめ細かい承認を使用することで、誰がどのような状況で何を実行できるかを制御できます。
  • コンプライアンス: 私たちが今日住んでいる世界を見てください。私たちは、業務分野 (銀行、保険、医療など) に応じて、多くの規制を順守する必要があります。これらの規制をコードで実装するのは困難ですが、XACML が提供するものとまったく同じポリシーとして表現するのは簡単です。

さらに詳しく知りたい場合は、JavaZone 2013 で Java と XACML に関するプレゼンテーションを行いました。スライドはこちらです。

どの SSO ソリューションを使用していますか? SiteMinder は、よりきめ細かい認証を実装するための認証 API (ActivePolicy) を提供します。それを見てください。

これが役立つことを願っています！

于 2013-10-25T12:28:15.723 に答える
2

認証に必要なロジックとデータを区別します。

承認ロジックを見ている場合、それはアプリケーションに固有のものです。なぜロジックを集中化する必要があるのですか? おそらく、同じ承認ロジックが複数のアプリケーションで使用され、そのような承認ロジックが変更される可能性があります。ただし、多くのアプリケーションはこれを必要とせず、すべての承認ロジックを外部化するアプリケーションの開発は、必要な時間とコストのために、常に実行可能なオプションであるとは限りません。この目的のためには、いくつかのポリシー仕様言語が必要であり、各クライアント アプリでインタープリターを使用する必要があります。

認証に必要なデータを一元化することは、上記よりもはるかに単純なタスクであり、おそらくより頻繁に必要とされる機能です。ただし、必要なデータがサブジェクトではなくドメイン オブジェクトに依存する場合は、やはり上記のケースになります。同じユーザー ロールまたは属性が同様に適用される一連のアプリケーションがある場合、これを行う価値がさらにあると思います (また、必要になる可能性もあります)。別のケースとして、1 人のグループによる集中型の承認管理が必要になる場合があります。これは、アプリケーションに当てはまる場合と当てはまらない場合があります。

ある解決策を他の解決策よりも処方することは、私が好きなことではありません. この性質の質問に対してはい/いいえの答えを出す必要がある場合は、他の側面も評価します. 例えば、

  1. 既存のアプリケーション、その実装言語、プラットフォーム、変更オーバーヘッド、および使用されている既存の承認メカニズム。
  2. 正確に何を集中化する必要がありますか (ロジック、データ)?
  3. 一元化された承認の複雑さは正当化されますか?
  4. ネットワーク通信のオーバーヘッドと追加のレイテンシ
  5. これは、システムと部品のテスト容易性にどのように影響しますか?
  6. ... このリストは簡単には終わりません...
于 2013-10-25T18:32:59.580 に答える