私たちは、公共機関と一緒に、さまざまなオープンソースツールをインストールして実験し、彼らに最も適したものを確認する演習を進めています。
したがって、インストールしています：
そしておそらくもっと。
ログインを調和させるためにLDAPを使用することを考えていました。
しかし、多くの場合、LDAPプラグインはもう維持されていないと思われ、設定がうまく機能しにくく、一部のツールではLDAPドキュメントが不十分です。
LDAPを介してこれを行うことは、今日でも良い考えですか？OAuthはより良い選択でしょうか？
これはコードの問題ではないことはわかっていますが、LDAPに移行するという決定に固執する必要があるかどうか、または他のパスを検討する必要があるかどうかを理解したいと思います。どうもありがとう
回答:
LDAPはシングルサインオンを提供できません。同じユーザーを使用できることとシングルサインオンを使用することの間には大きな違いがあります。つまり、単一のログインフォームで一度にすべてのシステムにログインします。それ以外の場合、LDAPはすべてのシステムで同じログイン情報を使用するのに完全に適しています。
OAuthはサインオンを行うためのプロトコルにすぎず、LDAPをユーザー管理のバックエンドとして使用できます。
大学の世界では、Apereo [旧Jasig] CASシステムは、Webアプリケーションの大規模なスイートに対してシングルサインオンを行う一般的な方法です。CASを使用すると、ユーザーは認証サーバーにパスワードを入力するだけです。個々のアプリケーションは、ユーザーのパスワードを確認する代わりにワンタイムチケットを検証します。多くの社内グループやベンダーによって開発されたアプリケーションを扱う場合、これは大きなセキュリティ上の勝利です。どのアプリケーションもユーザーのパスワードにアクセスできないためです。
ほとんどのプログラミング環境で使用できるCASクライアントライブラリは数多くあり、組み込みのCASサポートは、大学で使用または販売されるアプリケーションでより一般的になっています。メインの「Jasig CASサーバー」に加えて、Ruby CASサーバーや、Drupalデータベースに対して追加のアプリケーションを認証するためのCASサーバーとして機能するDrupalのモジュールなど、いくつかの追加サーバーも利用できます。
Jasig CASサーバー自体はJavaで記述されており、次のような任意の数の認証ハンドラーを利用できます。
Jasig CASサーバーは、シングルサインオンに使用されるさまざまなプロトコルを介して、アプリケーションの認証ソースとして機能できます。
Shibbolethプロバイダーの背後で認証として使用したり、Shibbolethクライアントを認証バックエンドとして使用したりすることもできます。
注：Jasig組織はApereo組織と統合されているため、一部のURLは将来変更される可能性があります。