565
szerkesztés
Módosítások
→Shibboleth 2.x IdP X.509/LDAP autentikációs modul
= Shibboleth 2.x IdP X.509/LDAP autentikációs modul =
Ezen az oldalon az NIIF által fejlesztett X.509 klienstanúsítvány alapú Shibboleth autentikációs modul leírása szerepel.
== In English ==
=== Motivations ===
* The use of hardware tokens as authentication source. However, X.509 certificate authentication is not generally considered secure by nature, hardware tokens are designed to be safer than passwords. Local policy can decide whether they accept software tokens or not.
* Give the choice to our SPs. Some SPs can decide if they wanted to force the X.509 authentication (or force password authentication).
=== PKIful versus PKIless ===
* If one has built their full-fledged PKI infrastructure, one could use it for client certificate authentication.
* But it is hard to do PKI right, CRLs and/or OCSP are crucial in PKI.
* If only authentication is needed, storing the (self-signed) certificate is enough.
=== Shibboleth X.509 authentication ===
* With PKI, you would use simple RemoteUser authentication with container support.
* Without PKI, the container can not authenticate the user, it can only check if the user has the corresponding private key.
* You will also need some custom workflow to validate the presented client certificates. Eg. checking them against the directory attribute 'userCertificate'. This is step is a must to have control over certificate revocation.
=== X.509 + LDAP certificate authentication (implementation details) ===
* The web container does client certificate checking, but does not validate. Instead, it handles the certificate to the Shibboleth authentication module which will validate it.
* Shibboleth is configured with RemoteUser login handler pointing to our X.509 authentication servlet.
* The certificate must contain some identification data (eg the X.500 'UID' RDN). Our authentication servlet takes the presented certificate and compares it to the stored certificate(s) for the user. If a matching certificate is found in the directory, then the user is authenticated.
* The certificate authentication is implemented as a standard JAAS module, and can be reused elsewhere.
=== Combining X.509 and username/password authentication ===
* We want to make sure the user can not override the requested method, implementation of Shibboleth IdP issue SIDP-258 is needed for this.
* When SP does not specifically request an authentication method, the user should have the choice between supported authentication modes.
* One can tweak the UsernamePassword login page to have links for X.509 authentication servlet and end up with three different authentication handlers:
** UsernamePasswordX509 hybrid handler with 'unspecified' authentication method class. This handler invokes the UsernamePasswordX509LoginServlet which takes care of user choices on the extended login page.
** RemoteUser login handler with protected servlet location /Authn/X509, where our custom X.509 authentication servlet lives.
** UsernamePassword login handler.
* These last two login handlers must ensure that the corresponding authentication method class is set in the Shibboleth request. When user authenticates with X.509, clients would receive the X509 class, and with UsernamePassword, they would receive PasswordProtectedTransport, respectively.
* Playing with Shibboleth login handlers and authentication contexts revealed that Shibboleth IdP can not properly support default authentication methods, and our hybrid handler with its 'unspecified' authentication method is invoked on every authentication request, even when the user has a valid previous session. Fixing SIDP-265 with our proposed patch corrected this flaw.
== Követelmények ==
