パスワードが爆発して、魔法の煙サーバーから取り出して設定するlp0 燃える?
真面目な話、ユーザー名とパスワードが必要な場所の数は劇的に増加しています。オープンID近い将来に問題は解決されないだろうし、シングル・サインオン外部の巨大なネットワークを無視しても、内部的には現実というよりは目標のように思えます。
先ほど会議から帰ってきたところですが、そこでは、いくつかの外部サイトへのアクセスに料金を支払っており、ハードルを下げて、スタッフ (および学生) がこれらのリソースを利用する可能性を高めたいと説明されました。発言者は、上位 5 ～ 10 パーセントのユーザーがこれらのサイトを利用する可能性があると感じていましたが、ユーザーがサイトにログインできる方法 (および開始ページ) を提供できれば、利用率は大幅に向上する可能性があると感じていました (また、テクニカル サポートの費用を節約できるだけでなく、パスワードを忘れたユーザーを支援する必要もありません)。
あなたの組織ではこの問題に対してどのような対策を講じていますか? 何か賢明なアプローチはありますか?
答え1
Kerberos を使用すると、90% の問題が解決します。次に、ブラウザで Kerberos トークンを内部 Web サイトに渡すようにする必要があります (Mozilla の各種の about:config で「nego」を検索して設定を確認してください)。
その後、パスワードが必要なものについては RADIUS タイプの認証、または LDAP を使用します。
答え2
私たちは中央認証サービス（ウィキペディアのエントリー）。多くのプラグインがあり、ユーザーごとに個別のID情報を持つサービスにも使用できました。信じるまた、サイトへの一般的なログインがあるサービスにも使用できます。
答え3
そこにはキーパスオプション。Keepass では、Web サイトを開き、正しいログイン フィールドまでタブ移動し、ユーザー名とパスワードを入力して Enter キーを押すという操作を 1 回のクリックで簡単に実行できます。事前に入力された keepass DB をペンドライブに保存してユーザーに渡すと、ユーザーは自分のパスワードもそこに保存できます。
何千人ものユーザーを対象とする Web ベースのログイン システムには不十分かもしれませんが、パスワードが安全であることにユーザーが安心感を覚えるようになるかもしれません (個々のユーザーにとっては依然として優れたソリューションです)。
答え4
さまざまなツール/サイト/サービスがLDAPをサポートしている場合、ログイン時に5月必須ではありませんが、少なくとも OpenLDAP または Active Directory インフラストラクチャに認証が返されるので、ユーザー名とパスワードは「新しい」ものにはなりません。