さまざまな意見を求めているだけです。OpenID は優れた「シングル サインオン」ソリューションだと思いますか?
それが機能する方法は、平均的なユーザーにとって少し混乱しているようで、「すべての卵を同じバスケットに入れる」ことに関連する問題が発生する可能性があります.
とにかく、多くの異なるアプリケーション (Wordpress、Elgg、Media Wiki など) が存在するイントラネットのコンテキスト内で、独自の OpenId ソリューションを実装しようとした人はいますか??
「デジタルアイデンティティ」の問題を解決するための優れたソリューションになると思いますが、「一度ログインしてイントラネットを閲覧する」問題で機能するかどうかはわかりません.
意見？
また、SSO (あなたが述べたように) は通常、(おそらくワークステーションに) 1 回ログインするだけでよく、それ以降はどこにもサインインする必要がないことを意味します。
もちろん、OpenID はその問題を解決しません。たとえば、OpenID を使用して StackOverflow にサインインしたとしても、同じ openID を使用して別の Web サイトに再度サインインする必要がないわけではありません。
「平均的な」インターネット ユーザーにとっては難しすぎるという意見には完全に同意すると言わざるを得ません。最初の提案は 2005 年にさかのぼりますが、OpenID は依然として「新しい」と見なすことができると思います。トラフィックの多いサイトでは、ユーザーに OpenID の存在を要求するのではなく、アカウントを作成するための単なるオプションとして採用しています。
私の意見では、通常のユーザー名/パスワードによるアカウント作成が OpenID と一緒に提供されている限り、平均的なインターネット ユーザーは自然に OpenID の使用を試み始め、最終的には使い続けるでしょう。
認証の問題は、Web サイトへの登録と同じように OpenID にも当てはまります。パスワードを使用して Web サイトを信頼しているため (パスワード保存プログラムを使用していないと仮定して)、OpenID に対して使用しないでください。
それはさておき、アカウント作成の標準化は、Web 開発者にとって絶対に難しいことです。通常の作成プロセスについて心配する必要さえなく、OpenID ライブラリにドロップしてデータベースを参照するだけでよいと思います。
OpenID (非常に多くのプロバイダー) を理解するのに少し時間がかかりましたが、この概念はとても気に入っています。これを Gravatar と結び付ければ、プロファイルの書き換えははるかに楽になります (おそらく 1 つまたは 2 つのフィールド)。
唯一の問題は、OpenID プロバイダーを信頼する必要があることですが、それは私が問題と呼ぶものではなく、むしろ常識のようなものです。
編集: OpenID プロバイダーに問題がある人は、新しいプロバイダーの設定を検討する必要があります。私のプロバイダーは myopenid.com で、問題はありません。複数のペルソナ (プロファイルなど) を設定できるので、ブログのコメント用に 1 つ、このようなテクノロジー サイト用に 1 つ用意しています。
新しい SO プロファイルを持つことに関して、Jeff は、将来プロファイル統計を失うことなく OpenID を変更できることについて述べました。
OpenID には小さな問題が 1 つあります。
OpenID でシームレスにログインするには、ドメイン間の自動 (未検証) リダイレクトが必要です。
これにより、OpenID サーバーはサードパーティになります。これにより、サード パーティの Cookie をオフにし、ブラウザーが RFC2965 の 3.3.6 の検証不能なトランザクション ルールに厳密に従っている場合、OpenID サーバーの Cookie が拒否される可能性があります。
この例は Opera です。サード パーティの Cookie をオフにすると (グローバルを [アクセスしたサイトからの Cookie のみを受け入れる] に設定して)、OpenID でログインできません。 OpenID サーバーに接続すると、OpenID サーバーは同じことを行ってユーザーを戻します。
ただし、Firefox、IE、および Safari では、対応するサード パーティの Cookie をブロックすることで幸運に恵まれます。それらは複数の状況で RFC2965 に違反しているためです。
この場合に OpenID を使用しなければならないことは、より準拠しているクライアントに不利益をもたらします。
回避策として、Opera では、すべての Cookie を受け入れる以外に、ツール -> 設定 -> 詳細設定 -> ネットワークに移動して、自動リダイレクトをオフにすることができます。その後、リダイレクト先の各リンクを確認してクリックすることができ、トランザクションが確認されるため Cookie が拒否されることはありません。
自動リダイレクトをオンのままにし、両方のサーバーがクリックするリンクを含むページを生成して、トランザクションを確認できる場合にも機能するはずです。ただし、自動リダイレクトはどこにもありません。
この場合、ファースト パーティの Cookie のみを扱う場合は、ユーザー名とパスワードだけでログインする方がはるかに優れています。
ただし、OpenID はまだクールであり、ここで「アクセスしたサイトからの Cookie のみを受け入れる」を使用できるように、SO と OpenID サーバー間の検証不可能なトランザクションを許可するオプションが Opera に必要なだけだと思います。
誰かがシングルサインオンについて簡単に説明できますか？SSO が OpenID と SSO の違いをよく説明しているので、openid を使用したい:
シングル サインオンとは、ある場所でログオンすると、他の場所で自動的に認証されることです。OpenID とは、認証を OpenID プロバイダーに委任することで、1 セットの資格情報で複数のサイトに効率的にログオンできるようにします。
同じ投稿は、元の質問に対する優れた回答も提供します。
SSO の認証スキームとして OpenID を使用することもできますが、これは付随的なことです。
私は OpenID についてかなり曖昧です。一方では、「ID プロバイダーの検出問題」 (証明書利用者サイトが認証のためにユーザーを送信する場所をどのように判断するか) に対処します。一方で、URL は平均的なユーザーにとって非常に扱いにくいものです。
OpenID は現在のところ、Web ID のソリューションへの道のりの便利な立ち寄り先であると考えていますが、最終的な目的地ではないことは確かです。
イントラネットの質問に具体的に答えると、OpenID はおそらく正しい答えではありません。上で述べたように、OpenID を使用すると、ID プロバイダーを見つけることができますが、その代償として、すべての依存側でその URL を入力する必要があります。何らかの内部 ID プロバイダーですべてのユーザーを認証し、その ID プロバイダーからのユーザーのみを受け入れる場合、OpenID は実際にはあまり役に立ちません。
CASやOpenSSOなどのシステムを検討します。どちらも URL を入力しなくてもユーザーをログイン ページにリダイレクトします。私は最近、IIS 6.0、Apache、JBoss、および Tomcat 上のアプリを使用して、わずか 4 か月で 3000 人のユーザー向けの 40 のイントラネット アプリケーションに OpenSSO を展開した会社についてブログに書きました。
私は、OpenID がユーザーに強制するには、あまりにも複雑で扱いにくいと考えています。また、OpenID が真の問題を解決しているとは確信していません。私が使用する各サイトに登録する必要があることは、大きな問題として私を襲ったことはありません. 特に、その問題を特に解決するわけではないので。OpenID を StackOverflow にリンクしたとき、とにかく追加の詳細を記入する必要がありました。それがもたらすすべての違いのために、定期的な登録プロセスがあったかもしれません.
まあ..単純な login-pwd の組み合わせがよかったと思います (Passwordmaker.org で簡単に解決できます)。しかし、開発者として、彼らがログイン ホイールを再発明したくないことは理解できます...
OpenID:
ブログの URL を入力 => Google サインイン => I'm in.
それは余分なレベルです..しかし、それはOKです。
OpenIDの実装には多大な労力が必要であり、成功するためには考えられます。それでも、不正なIDプロバイダー（Yahooなど）に妨害される可能性があります。OpenIDは、ユーザーエクスペリエンスの問題を解決した場合に非常にうまく機能しますが、ほとんどのユーザーにとって、不適切な実装は非常に困難です。私の意見では、OpenIDの最大の問題は、人々がユーザーの意識を持って問題を解決しようとしたことです。OpenIDプロバイダーのリストを提供し、ユーザーに使用したいプロバイダーをクリックしてもらうほうがよいでしょう。これには、プロバイダーがバージョン2.0の仕様をサポートしていない場合にOpenIDを実装する方法についての知識が必要になることがありますが、エンドユーザーの全体的なエクスペリエンスははるかに優れています。
とにかくすべてのユーザーがプログラマーであるため、スタック オーバーフローに関してはそれほどユーザビリティの問題ではありませんが、それを回避できる他の多くのサイトは考えられません。
openID は時間の経過とともに改善されると思いますが、openID を使用しているすべてのサイトがすべての機能 (自己紹介の自動入力など) の実装を開始すると、より価値のあるものになるでしょう。
もちろん、OpenID はその問題を解決しません。たとえば、OpenID を使用して StackOverflow にサインインしたとしても、同じ openID を使用して別の Web サイトに再度サインインする必要がないわけではありません。-- tj9991
しかし、それはそれを意味する可能性があります。OpenID サイトでのサインオンが (Cookie などによって) 記憶されている場合、事実上、アクセスするすべての OpenID サイトに対して、ブラウザー セッションごとに 1 回 (または週に 1 回、月に 1 回...) サインオンするだけで済みます。 .
ブラウザーのサポートと API によって、パスワード プロンプトとページ リダイレクトが不要になることさえあります。いい案！
実際、StackOverflow の場合、別のアカウントを使用すると、多くの手間が省けました。WordPress.com の OpenID を使用することにしましたが、WordPress.com は OpenID サービスに深刻な問題を抱えており、ほとんどの場合、StackOverflow にログオンできません。まったく。もちろん、別の OpenID プロバイダーを使用してログオンすることもできますが、その場合、サイトで別の ID を持つことになります。
これは WordPress.com のせいだと言えるかもしれませんが、問題は同じままです。OpenID を使用することで、別のサイトのサービスに依存して機能することになります。サードパーティのサイトに問題があると、事実上、サイトも無効になります。
別の解決策として、Yahoo OpenID でサインインしようとしましたが、ユーザー名としてランダムな文字列を取得しました。DrPizza がすでに指摘したように、とにかく個人情報を編集する必要があります。
OpenID は素晴らしいアイデアですが、現状ではまだ信頼できるものではありません。
少なくともイントラネットのシナリオでは、Active Directory (または同様のもの) が依然として最良の選択肢の 1 つだと思います。
少なくともイントラネットのシナリオでは、Active Directory (または同様のもの) が依然として最良の選択肢の 1 つだと思います。
はい、いずれにせよ、Active Directory は OpenId サーバー プロバイダーの背後にあります。
イントラネット内で SSO ソリューションを開発するには、Access Manager (旧 IChain) + Active Directory などの商用オプションがありますが、「独自の OpenId サーバー」+「まだ開発されていないクールなもの」以外にオープンなソリューションがあるかどうかはわかりません+ LDAP。