generische Authentifizierung

[cmrudolph]

Hi,

ich habe ein Interface für Klassen, die sich irgendwo anmelden können. Nun möchte ich diesen Klassen Zugangsdaten injizieren. Das Problem ist, dass die Zugangsdaten teilweise vollkommen unterschiedlich geartet sind.
Meistens sind es einfach nur Paare aus Nutzernamen und Passwort, manchmal ist es aber auch ein Clientzertifikat oder ein Tokenstring.
Ich komme mir irgendwie doof vor, wenn ich jetzt ein Interface implementiere das so aussieht:

public interface Credentials {
    String getUserName();
    String getPassword();
    String getToken();
    X509Certificate getCertificate();
    //...
}

Gibt es eine elegantere Lösung um eine möglichst generische Authentifizierung zu gewähren?

 

[Auth]

Ich denke das da so sicher nicht möglich sein wird da es ja nun mal eine vielzahl unterschiedlicher Auth-Methoden gibt.
Du könntest zwar gewisse Untergruppen erstellen, z.b. eine Gruppe die sich mit Username und Passwort begnügt. Die Implementierung erzeugt dann daraus für die Auth gültige Daten.
Eine andere wäre z.B. alles was Zertifikats basiert abläuft.

Das problem ist das es einfach zu viele verschiedene Arten der Authetifizierung gibt das man nun nicht alles unter einem generischen Hut bekommt ohne das das ganze dann so aufgebläht wird das nun mal alles drin ist.

 

[cmrudolph]

Genau das ist das Problem. Ich habe auch schon versucht einen Weg in der Art

public interface Authenticator {
    doAuthenticate(Object context);
}

zu überlegen. Dazu müsste aber der Authenticator Details über den Authentifizierungsvorgang kennen.

Hat vielleicht jemand eine Idee, wie man die Kontrolle sonst noch "umdrehen" kann?

 

[Auth]

Wie ich bereits sagte : alles unter einen Hut bekommen wird schwierig. Es gibt halt zu viele verschiedene Arten. Also brauchst du für diese vielen verschiedenen Arten auch entsprechend viele verschiedene Implementierungen. Da nun aber auch alle Arten unterschiedliche Informationen brauchen sollte man diese in der jeweiligen Implementierung bzw. falls möglich deren "Gruppe" (also Super-Klasse) definieren.
Man könnte dann vielleicht noch mit Factory-Methoden arbeiten die dann auf Grund der übergebenen Daten ein entsprechendes Objekt liefern, aber ob es Sinn macht das dann so weit zu abstrahieren das man nur noch ein großes Interface (VORSICHT : "Authenticator" gibt es bereits : java.net.Authenticator) hat in dem dann eine Methode ala "doAuth()" vorgegeben wird?
Problem wird auch sein das halt einige Auth-Methoden etwas returnen und andere nicht. Und da wird eine einzige Methode schon nicht mehr ausreichen (es sei denn du deklarierst "Object" und returnst bei denen die nichts returnen NULL, was aber nicht Sinn von NULL ist).

 

[Volvagia]

Beim Authentifikationsvorgang wird ja wahrscheinlich auch ein Objekt mit den Daten erzeugen, oder? Geht dann nicht einfach ein Interface Authenticator (vergessen wir mal das es das schon gibt) und AuthenticateData, welche bei der Authentifizierung generiert wird. Hinter dem Authenticator liegen Dinge wie Rechte, Daten oder was auch immer. Von den beiden Interfacen erben z. B. PasswordAuthenticator und PasswordAuthenticateData. Wenn jetzt eine AuthenticateData-Instance reinkommt werden die Authenticater der Reihe nach eine Methode wie isType(data) aufgerufen. Diese prüft mittels Zahlencode oder instanceof oder soetwas, ob die Data und der Authenticator (this) zusammengehören. Wenn ja wird eine andere Methode aufgerufen in der gecastet und geprüft wird. Nach erfolgreicher Authentifizierung könnte der Authenticator ein Interface instanzieren, das als Schnittstelle, also sozusagen als Tunnel durch die Authentifizierung zu den Daten führt. Natürlich geht das nur, sofern die Daten wenigstens im Ansatz bekannt sind.

 

[bERt0r]

Dann verwende doch Generics:

public interface Authenticator<T>
{
public T getAuthentication();
}

 

[Marcinek]

Schau dir mal Apache Shiro an.

 

[cmrudolph]

An Generics habe ich auch schon gedacht. Ich habe nur keine Möglichkeit gefunden, daraus einen Vorteil zu erlangen. Denn man müsste in diesem Fall mit Wildcards arbeiten - dadurch ist die ganze Typsicherheit wieder weg. Schlimmer noch, man kann nichtmal mehr zur Laufzeit richtig prüfen, welchen Typ das Objekt hat.

Der Tipp mit Apache Shiro ist sehr interessant. Das ist ein Framework, das ich bestimmt noch einmal verwenden werde. Für meine derzeitigen Zwecke ist es allerdings nicht das richtige.

In Shiro ist das in etwa so gelöst (Kurzversion):

public interface AuthenticationToken {
    Object getCredentials();
    Object getPrincipal();
}

AuthenticationToken (Apache Shiro 1.2.0 API)

Eine Username/Passwort Kombination sieht so aus:
UsernamePasswordToken (Apache Shiro 1.2.0 API)

Da werde ich wohl ein ähnliches Interface gestalten und dann zur Laufzeit prüfen, ob der Typ richtig war. Wobei diese Laufzeitprüfungen meiner Meinung nach bei Authentifizierung gar nicht soo schlimm sind, weil bei einer Authentifizierung prinzipbedingt sehr häufig Exceptions fliegen. Eine "InvalidCredentialsException" würde ja auch dann passen, wenn man den falschen Authentifizierungsmechanismus - also beispielsweise ein Zertifikat statt eine Username/Passwort Kombination - gewählt hat.