属性証明書とアクセス管理
私は最近 Attribute Certificates （RFC 5755）に出会いました。これは、許可の手段として使用できます。
アイデアは好きですが、これが実際の生活の中でどのように機能するかについての情報を探すのに長い時間を費やしてきました。属性証明書の目的は理解していますが、これがどのように使用されるのかわかりません。
たとえば、Webアプリケーションがあります。 Webアプリケーションのアクセス管理に属性証明書を使用するにはどうすればよいですか？属性証明書を処理できるWebアプリケーションの認証レイヤーに何かが必要です。これはどのように達成されますか？実際のWebアプリケーションで例を見つけることができません。
また、属性証明書をサポートし、属性機関とともに属性証明書を提供できるアクセス管理ツールはありますか？私は PERMISプロジェクト を見つけることができますが、時代遅れであり、もう役に立たないようです。
理論や考えられるユースケースではなく、アクセス管理のための属性証明書の実際のアプリケーションを見たいです。
real実生活では、属性証明書は機能しません。誰も本当にそれらをサポートしていません。その理由の1つは、証明書が、定義上、情報の非同期配布方法であることです。証明書は、いくつかの値をバインドします（「通常の」証明書の場合、これは名前と公開鍵です。属性証明書の場合、所有者名）は属性値にバインドされています）。中央のオンラインリポジトリと通信しなくてもバインドを検証できます。これは、証明書の暗号化署名に関するものです。オフラインまたは少なくともセミオフラインの検証を可能にするためです。
オフライン検証の裏側は、証明書をすぐにキャンセルする方法がないことです。 失効がありますが、本質的に非同期です。証明書が失効すると、数時間または数日以内に有効になります（CRLが生成される頻度に応じて異なります）。非同期はまさに承認に必要のないものです：悪意のあるアクティビティの疑いがあるために誰かをブロックしたい場合は、次ではなくnowにしたいです週間。
OCSPサーバーと通信することにより、すべてのクライアントに毎回新しい失効情報を取得させることにより、同期失効を行うことは可能ですが、これにより、そもそも証明書が必要だった理由が無効になります。証明書を使用する主な目的は、認証情報が必要になるたびにオンラインサーバーと通信する必要がないようにすることです。
したがって、基本的に、証明書と承認はうまく混合されません。これにより、承認用のRFC 5755属性証明書がまったく役に立たなくなります。同様に、それらはあまり使用されていません。
RFC 5755 の紹介では、属性証明書の使用目的について説明しています。ここにテキストをコピーします。
一部の人々は常にPKCとACを混同しています。類推によって区別が明確になる場合があります。 PKCはパスポートのようなものと考えることができます。これは所有者を識別し、長期間続く傾向があり、取得するのは簡単なことではありません。 ACは、入国ビザに似ています。通常、別の機関によって発行され、有効期間は長くありません。通常、入国ビザを取得するにはパスポートを提示する必要があるため、ビザの取得はより簡単なプロセスです。
Webアプリケーションでは、ユーザー認証には引き続きPK証明書が必要であり、属性証明書は承認/アクセス管理を提供します。ユーザーは、アプリケーションに接続するために両方を提示する必要があります。
RFC 5755を読むと、他のいくつかの使用例が明らかになります。採用が遅く、オンラインで検索しても多くの例が見つからないのは事実ですが、属性証明書はセキュリティアプリケーションで使用されています。