Authentifizierungsverfahren mit RSA-Token

Das Authentifizierungsverfahren Rivest Shamir Adleman (RSA) wird verwendet, um die Sicherheitsumgebung für die flexible Verwaltungstopologie zu vereinfachen. Das Verfahren unterstützt die Fähigkeit, neue Server sicher und ohne großen Aufwand in der flexiblen Verwaltungstopologie zu registrieren. Mit der flexiblen Verwaltungstopologie können Sie Verwaltungsjobs lokal oder über Fernzugriff übergeben und verwalten, indem Sie einen Job-Manager verwenden, der Anwendungen verwaltet, die Produktwartung durchführt, Konfigurationen ändert und die Laufzeitumgebung des Anwendungsservers steuert. Das Authentifizierungsverfahren RSA wird nur für die administrative Authentifizierung zwischen Servern verwendet, z. B. für Administratoverbindungs- und Dateiübertragungsanforderungen. Das Authentifizierungsverfahren RSA ist kein Ersatz für LTPA oder Kerberos für Anwendungen.

Anmerkung: Das Authentifizierungsverfahren mit RSA-Token unterstützt das flexible Verwaltungsziel, die Basisprofilkonfigurationen zu bewahren und von einer Sicherheitsperspektive zu trennen. Durch diesen Mechanismus können die von einem Verwaltungsagenten verwalteten Basisprofile verschiedene LTPA-Schlüssel, unterschiedliche Benutzerregistrys und verschiedene Benutzer mit Verwaltungsaufgaben haben.
Wichtig: Das RSA-Token ist nicht mit dem RSA-SecureId-Token verknüpft. Beachten Sie, dass der Anwendungsserver keine Unterstützung für SecureId bietet.

Authentifizierung ist der Prozess, der ermittelt, ob die Identität eines Clients in einem bestimmten Kontext authentisch ist. Ein Client kann entweder ein Endbenutzer, eine Maschine oder eine Anwendung sein. Ein Authentifizierungsverfahren in WebSphere Application Server arbeitet gewöhnlich eng mit einer Benutzerregistry zusammen. Die Benutzerregistry ist das Repository für Benutzer- und Gruppenkonten, das das Authentifizierungsverfahren bei der Authentifizierung abfragt. Das Authentifizierungsverfahren ist verantwortlich für das Erzeugen eines Berechtigungsnachweises, der die produktinterne Darstellung eines erfolgreich authentifizierten Clientbenutzers ist. Nicht alle Berechtigungsnachweise werden gleich erzeugt. Die Möglichkeiten des Berechtigungsnachweises werden durch den konfigurierten Authentifizierungsmechanismus bestimmt.

Authentifizierungsprozess

Das Authentifizierungsverfahren mit RSA-Token stellt sicher, dass nach dem Austausch des RSA-Stammunterzeichnerzertifikats (15 Jahre Laufzeit) zwischen zwei administrativen Prozessen keine Synchronisation der Sicherheitsinformationen zwischen unterschiedlichen Profilen für Verwaltungsanforderungen erforderlich ist. Das persönliche RSA-Zertifikat (1 Jahr Laufzeit) wird zur Ausführung der Verschlüsselungsoperationen für RSA-Token verwendet und kann von dem RSA-Stammzertifikat mit langer Laufzeit verifiziert werden. Das Authentifizierungsverfahren mit RSA-Token unterscheidet sich von der LTPA-Authentifizierung, bei der Schlüssel gemeinsam genutzt werden und bei der sich alle Seiten ändern müssen, wenn eine Seite geändert wird. Da das Authentifizierungsverfahren mit RSA-Token auf einer PKI-Infrastruktur basiert, profitiert es in großen Topologien von der Skalierbarkeit und dem Verwaltungskomfort dieser Technologie.

Ein RSA-Token verfügt gegenüber LTPA über erweiterte Sicherheitsfunktionen. Dazu gehören ein Nonce-Wert, wodurch es zu einem Token mit einmaliger Verwendung wird, eine kurze Verfallszeit (da es sich um ein Token mit einmaliger Verwendung handelt) und Anerkennung, die auf der Basis der Zertifikate im Ziel-RSA-Truststore hergestellt wird.

Das Authentifizierungsverfahren mit RSA-Token verwendet nicht dieselben Zertifikate wie SSL (Secure Sockets Layer). Dies ist der Grund dafür, dass RSA über eigene Keystores verfügt. Damit die für RSA hergestellte Anerkennung eingegrenzt wird, müssen sich Truststore, Keystore und Stamm-Keystore von der SSL-Konfiguration unterscheiden.
Anmerkung: Persönliche SSL-Zertifikate, die reinen Clients zugeteilt werden, werden häufig mit demselben SSL-Stammzertifikat signiert, das von Servern verwendet wird. Dies erlaubt es einem reinen Client, ein RSA-Token an einen Server zu senden und als Administrator zu fungieren. Dies sollte bei Verwendung des Authentifizierungsverfahrens mit RSA-Token vermieden werden. Das Authentifizierungsverfahren mit RSA-Token verwendet ein eigenes Stammzertifikat, das persönliche Zertifikate unterzeichnet, die zum Verschlüsseln und Signieren von Teilen des Tokens verwendet werden.
Die in einem RSA-Token gespeicherten Daten basieren auf der Identität des Clientsubjekts. Das Clientsubjekt kann auf LTPA oder Kerberos basieren, aber das RSA-Token verwendet diesen Schutz nicht für Verwaltungsanforderungen. Das RSA-Token ist einfacher in seiner Verwendung und bietet gleichzeitig eine sichere Übertragung der Identität. Das RSA-Token enthält folgende Daten:
  • Version
  • Nonce
  • Verfallsdatum
  • Realm
  • Principal
  • Zugriffs-ID
  • Rollen (derzeit nicht verwendet)
  • Gruppen
  • Angepasste Daten
Angepasste Daten können auf der sendenden Seite ((bevor sie abgehen) zu "WSCredential" hinzugefügt werden, indem ein Eigenschaftenobjekt erstellt, angepasste Attribute hinzugefügt und dies wie folgt zu "WSCredential" hinzugefügt wird:
import com.ibm.websphere.security.cred.WSCredential;

java.util.Properties props = new java.util.Properties();
props.setProperty("myAttribute", "myValue");
WSCredential.put ("customRSAProperties", props);
Sobald das Subjekt im Zielprozess erstellt wurde, können Sie wie folgt auf diese Attribute zugreifen:
java.util.Properties props = (java.util.Properties) WSCredential.get("customRSAProperties");

Diese Daten werden in eine Hashtabelle auf dem Ziel gestellt, und die Hashtabelle wird in einer JAAS-Anmeldung (Java™ Authentication and Authorization Service) verwendet, um ein Subjekt auf dem Ziel abzurufen, das dieselben Attribute aus dem RSA-Token enthält. Wenn das Ziel dieselben Attribute aus dem RSA-Token enthält, kann auf dem Ziel ein Subjekt abgerufen werden, das nicht in demselben Realm wie das Ziel enthalten ist. Damit diese Berechtigung erfolgreich ist, ist eine realmübergreifende Zuordnung in der administrativen Berechtigungstabelle erforderlich, sofern die Identität keine Trusted-Server-ID ist.

Die Abbildung weiter hinten in diesem Abschnitt enthält eine Übersicht über das Authentifizierungsverfahren mit RSA-Token und beschreibt den Prozess, der stattfindet, wenn eine Anforderung von einem Server als Client an einen Zielserver gesendet wird. Der als Client auftretende Server hat ein administratives Subjekt im Thread, das als Eingabe für die Erstellung des RSA-Tokens verwendet wird. Die andere Angabe, die benötigt wird, ist das öffentliche RSA-Zertifikat auf dem Zielserver. Dieses Zertifikat muss über eine "Bootstrap"-MBean-Anforderung an den Zielprozess abgerufen werden, bevor echte Anforderungen gesendet werden. Diese Bootstrapzielanforderung ruft das öffentliche Zertifikat vom Zielprozess ab. Beim Erstellen eines RSA-Tokens ist der wichtigste Grund für das Abrufen des öffentlichen Zertifikats des Ziels die Verschlüsselung des geheimen Schlüssels. Nur das Ziel kann den geheimen Schlüssel, mit dem die Benutzerdaten verschlüsselt wurden, entschlüsseln.

Diese Abbildung enthält eine Übersicht über das Authentifizierungsverfahren mit RSA-Token und beschreibt den Prozess, der stattfindet, wenn eine Anforderung von einem Server als Client an einen Zielserver gesendet wird. Der als Client auftretende Server hat ein administratives Subjekt im Thread, das als Eingabe für die Erstellung des RSA-Tokens verwendet wird. Die andere Angabe, die benötigt wird, ist das öffentliche RSA-Zertifikat auf dem Zielserver. Dieses Zertifikat muss mit einer Bootstrap-MBean-Anforderung an den Zielprozess abgerufen werden, bevor echte Anforderungen gesendet werden. Die Bootstrapzielanforderung ruft das öffentliche Zertifikat vom Zielprozess ab. Beim Erstellen eines RSA-Tokens ist der wichtigste Grund für das Abrufen des öffentlichen Zertifikats des Ziels die Verschlüsselung des geheimen Schlüssels. Nur das Ziel kann den geheimen Schlüssel, mit dem die Benutzerdaten verschlüsselt wurden, entschlüsseln.

Der private Schlüssel des Clients wird zum Signieren des geheimen Schlüssels und der Benutzerdaten verwendet. Der öffentliche Schlüssel des Clients ist in das RSA-Token integriert und wird auf dem Ziel validiert. Wenn der öffentliche Schlüssel des Clients beim Aufruf der CertPath-APIs auf dem Ziel nicht anerkannt wird, kann die RSA-Tokenvalidierung nicht fortgesetzt werden. Wird der öffentliche Schlüssel des Clients anerkannt, kann er zum Verifizieren des geheimen Schlüssels und der Benutzerdatensignaturen verwendet werden.

Das wichtigste Ziel ist die Umwandlung des Clientsubjekts in ein Subjekt auf dem Ziel, indem die dazu erforderlichen Informationen auf sichere Art und Weise weitergegeben werden. Nachdem das Subjekt auf dem Ziel generiert wurde, ist das RSA-Authentifizierungsverfahren abgeschlossen.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_7rsa_token_auth
Dateiname:csec_7rsa_token_auth.html