web-dev-qa-db-ja.com

OpenID、OAuth、またはSAMLによる認証をアウトソーシングする前に考慮すべき重要事項

一般的な認証プロバイダーの間で一貫した機能セットがないことは明らかです。

以下は、私が気付いた類似点と相違点を集約する試みですが、不足している追加機能、および外部委託プロバイダーを検討するときに考慮すべき重要な機能についてのアドバイスをいただければ幸いです。

認証

  • セッションごとの2要素認証（ Google 、 Verisign 、 MyOpenID ）
    • Blackberry、Android、iPhone、アプリケーション（ Verisign 、 Google ）
    • テキスト（MyOpenID、Google）
    • 音声（PhoneFactor、Google経由のMyOpenID）
    • ブラウザ証明書、および物理トークン（ Verisign ）
  • コンピューターごとの2要素認証： Facebook
  • ベータ（機能は変更される場合があります）Yahoo 2/22/13
  • パスワードの変更を強制（ LiveID 72日ごと）

プライバシー

  • メールアドレス非表示/非共有（LiveID、ClickPass）
  • ウェブサイトごとに一意のIDを提供します（ ClickPass ）
  • 情報共有コントロール（ Yahoo 、Facebook、Google、 LiveID 、 LiveIDServices ）

パスワードを忘れた機能

  • 最も安全（ Google には電話、OTP、および記入が難しい調査があります）

委任サポート

  • ベリサイン
  • ClickPass
  • （その他多数）

SignIn Seal/SiteKey

認証履歴を表示

  • 日付、アクション、ターゲットの完全なログ MyOpenID
  • ログは良好ですが、アクセスの監査には非効率的です Facebook
  • 認証の付与と削除に限定 Google 、 Yahoo

アクティブなセッションの概要

エンドユーザー機能

  • 簡単なサインイン/サインアッププロセス（ Aol ）
  • セキュリティを向上させるための「難しい」サインインプロセスのオプション（ Verisign ）、 この関連する質問も参照

接続されたアカウントをサポートします

トークンリプレイ保護

接続セキュリティ

質問

重要なアプリケーション機能を見逃しましたか？
プロバイダーを比較するときに注意してはいけない機能はありますか？

このリストに含まれていない追加情報の例には、暗号化の詳細、ISO/SAS70認定、またはプロバイダーがDNSSecを使用しているかどうかが含まれます。この情報を収集し、何が重要で何が重要でないかを優先する際に、助けを借りることができました。

追加情報を共有するか、間違いを修正してください。

passwordsprivacyfederationopenidoauth
19
goodguys_activate

正しい答えは明らかにアプリケーションによって異なります。

たとえば、次のようにリストしました。

セキュリティを向上させるための「難しい」サインインプロセスのオプション（ベリサイン）、この関連する質問も参照してください

このようなプロバイダーを使用することは、ログインのセキュリティ要件が低く、ユーザーベースを獲得するためのエントリへの障壁が低いことを強く望んでいるサイト（たとえば、stackexchangeやTwitter）にとってはひどい選択です。一方、金融取引を実行する必要があるサイトにとってはメリットになります。

ある程度は、ユーザーの好みとプロバイダーの評判の組み合わせにも依存します。サインアップするためにユーザーに例えばFacebookの使用を強制すると、Facebookを回避したユーザーを失う可能性があります。またはグーグル-彼らはすでに私について十分なデータを持っています、なぜ私があなたの、例えば、出会い系サイトにログインするたびに彼らに知らせたいのですか？

最後に、欠落している「機能」の1つは実際の（対約束された）のセキュリティの歴史です。特定のプロバイダーで一連の障害が発生した場合は、引き続き障害が発生する可能性があります。これは、既知の脆弱性を持たないプロバイダーが将来的に一部を公開しないということではありません。

4
bstpierre

アウトソーシングされたIDプロバイダー（IdP）を使用する場合の重要な問題は、信頼の位置です。あなたはそれらを信頼していますか？信頼係数はさまざまな形をとるので、フェデレーション信頼モデルの長所と短所をビジネススポンサーに説明してから、信頼モデルに進むことが不可欠です。

  1. IdPとの明示的または暗黙的な契約はありますか？ビジネスがサードパーティのIdPに依存している場合は、信頼できるIDでできることとできないこと、およびIdPが通知なしにサービスをプルできるかどうかについてコマーシャルを完全に理解する必要があるため、これは重要です。
  2. ユーザーが一般の人々であるかスタッフであるかは言いません。彼らがスタッフである場合、JML（参加者、脱退者、発動者）プロセスを検討し、関連するプロセスを用意して、誰が何を表示することを許可されているかを管理する必要があります。フェデレーションは多くの認証を適切に解決しますが、特権と承認は解決しません。
  3. 公開Webサイトで役立つ優れた連携メカニズムをいくつかリストしました。スタッフユーザー（つまり、独自のID）とも連携している場合は、SAMLコネクタが必要になることがあります。あなたはADFSについて言及しています。これは、SAMLv2コンプライアンスの点で過去に制限がありましたが、IdPツールとしてActive Directoryを使用する場合に最適です。業界には、Shibboleth（OSS）や "Federate"ツールを使用したPingなど、いくつかの主要なプレーヤーがいます。また、少し安いPing Connectソリューションもあります。ただし、これらは、IdPであり、サードパーティのサービスプロバイダー（SP）を使用している場合にのみ必要です。 Ping、IBM、およびCAにはフェデレーションツールがありますが、スペクトルの中で最も高価なものです。
3
Callum Wilson