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