547
szerkesztés
Módosítások
nincs szerkesztési összefoglaló
= 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 ===
* When SP does not specifically request authentication methods, the user should have the choice between supported authentication modes. Otherwise, the IdP must conform with the authentication context class the SP sent. The IdP must refuse to authenticate the user with authentication methods unacceptable to the SP. There is a support ticket named SIDP-258 about this flaw in Shibboleth IdP.
* We want to support two authentication methods: username/password (PasswordProtectedTransport) and X.509 authentication.
* Unfortunately this is not enough, we need a default authentication method which offers the choice of these two methods to our users. This can be done by placing a link to the X.509 authentication servlet in login.jsp. However when the SP requests PasswordProtectedTransport, this link must not be visible, so we decided to configure a new UserPassword login handler which maps to the unspecified authentication class and uses this tweaked login.jsp.
* We also want to send the actual authentication method to the SP (instead of saying 'unspecified'), so both login handlers must set their corresponding authentication class in the Shibboleth request. As the internal UsernamePassword login servlet does not do this, we subclassed it.
* 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 (because both actual methods it uses override this unspecified method in the request and IdP can not decide whether the unspecified class is requested by the SP or it is simply the default method configured in relying-party.xml). Fixing SIDP-265 with our proposed patch corrected this behavior.
== Követelmények ==
Ezen követelmények kielégíthetők a címtárban tárolt klienstanúsítványokkal, ugyanis a címtárba csak egy felettes szerv képes beírni a tanúsítványt, ott minden bejelentkezéskor ellenőrzésre is kerül, ezért könnyen visszavonható.
{{INFO_EN|A felhasználó tanúsítvány alapú azonosításához (identification) szükséges, hogy a tanúsítvány tartalmazza a felhasználónevet, mégpedig az <code>UID</code> (subject) mezőben.}}
== Telepítés ==
Az autentikációs modul letölthető az [a http://www.aaisoftware.niif.huoldalról.A Shibboleth2 IdP autentikációs motorjának konfigurációját részetesen a [https:/en/software aai webrőlwiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn Shibboleth2 User Authentication]wikioldal írja le.
=== Apache beállítása ===
...
<DefaultRelyingParty provider="foo..." defaultSigningCredentialRef="foo..."
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
...
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:X509" />
...
== Integráció a felhasználónév / jelszó bejelentkezéssel ==
