Die Sicherheitsattribute definieren Verschlüsselungs-, Validierungs- und Cookie-Informationen zur Festlegung der Sicherheitsebene für die Serverinstanz.
Es gibt folgende Verschlüsselungsattribute:
Gibt den zum Ver- und Entschlüsseln von Passwörtern verwendeten Schlüssel an und wird in der Konfiguration des Service Management-Systems gespeichert. Der Wert wird während der Installation festgelegt. Beispiel: dSB9LkwPCSoXfIKHVMhIt3bKgibtsggd
Der gemeinsame Grundschlüssel (Shared Secret) für das Anwendungsauthentifizierungsmodul. Der Wert wird während der Installation festgelegt. Beispiel: AQICPX9e1cxSxB2RSy1WG1+O4msWpt/6djZl
Standardwert: com.iplanet.services.util.JCEEncryption. Gibt die Implementierung der Verschlüsselungsklasse an. Verfügbare Klassen: com.iplanet.services.util.JCEEncryption und com.iplanet.services.util.JSSEncryption .
Standardwert: com.iplanet.am.util.JSSSecureRandomFactoryImp l. Gibt den Namen der Factory-Klasse für SecureRandomFactory an. Folgende Implementierungsklassen sind verfügbar:: com.iplanet.am.util.JSSSecureRandomFactoryImpl , die JSS verwendet, und com.iplanet.am.util.SecureRandomFactoryImpl , die reines Java verwendet.
Es gibt folgende Validierungsattribute:
Standardwert: 16384 bzw. 16 k. Gibt die maximale Inhaltslänge für eine HttpRequest an, die OpenSSO akzeptiert.
Der Standardwert ist "NO" (NEIN). Gibt an, ob die IP-Adresse des Client in allen SSOToken-Erstellungen bzw. -Validierungen überprüft wird oder nicht.
Es gibt folgende Cookie-Attribute:
Standardwert: iPlanetDirectoryPro. Der Name, den der Authentifizierungsdienst zur Festlegung der gültigen Sitzungs-Handler-ID verwendet. Der Wert dieses Cookie-Namens dient zum Abrufen der gültigen Sitzungsinformationen.
Ermöglicht die Festlegung des OpenSSO-Cookies in einem sicheren Modus, in dem der Browser das Cookie nur zurückgibt, wenn ein sicheres Protokoll, wie beispielsweise HTTP(s), verwendet wird. Der Standardwert lautet "false".
Mit dieser Eigenschaft kann OpenSSO den Vorgang URLencode für den Cookie-Wert durchführen, wodurch die Zeichen so umgewandelt werden, dass sie von HTTP verstanden werden können.
Mit den folgenden Attributen können Sie Schlüsselspeicherinformationen für zusätzliche Sites und Servers konfigurieren, die Sie erstellen:
Der Wert wird während der Installation festgelegt. Beispiel: OpenSSO-base /server_URI/keystore.jks. Gibt den Namen zur Passwortdatei für den SAML XML-Schlüsselspeicher an.
Der Wert wird während der Installation festgelegt. Beispiel: OpenSSO-base /server_URI/.storepass. Gibt den Namen zur storepass-Datei für den SAML XML-Schlüssel an.
Der Wert wird während der Installation festgelegt. Beispiel: OpenSSO-base /server_URI/.keypass Gibt den Pfad zur Passwortdatei für den SAML XML-Schlüssel an.
Der Standardwert ist "test" (Test).
Diese Attribute definieren das lokale Caching-Repository der Liste zurückgezogener Zertifikate (Certificate Revocation List, CRL), das zur Aufbewahrung der CRL von Zertifikatsautoritäten dient. Jeder Dienst, der eine CRL für die Zertifikatvalidierung benötigt, erhält die CRL auf der Grundlage dieser Informationen.
Gibt den Namen des LDAP-Servers an, auf dem die Zertifikate gespeichert sind. Der Standardwert ist der bei der Installation von OpenSSO angegebene Hostname. Es kann der Hostname jedes LDAP-Servers verwendet werden, auf dem die Zertifikate gespeichert werden.
Gibt die Anschlussnummer des LDAP-Servers an, auf dem die Zertifikate gespeichert sind. Der Standardwert ist der bei der Installation von OpenSSO angegebene Anschluss. Es kann die Anschlussnummer jedes LDAP-Servers verwendet werden, auf dem die Zertifikate gespeichert werden.
Legt fest, ob SSL für den Zugriff auf den LDAP-Server eingesetzt werden soll. In der Standardeinstellung greift der Dienst für die Zertifikatauthentifizierung ohne SSL auf den LDAP-Server zu.
Dieses Attribut gibt den BIND-DN des LDAP-Servers an.
Dieses Attribut legt das Passwort fest, dass für die Verbindung zum LDAP-Server verwendet wird. Standardmäßig wird das Passwort amldapuser, das während der Installation eingegeben wurde, als BIND-Passwort verwendet.
Dieses Attribut legt den vom LDAP-Benutzer-Betreff verwendeten Basis-DN des LDAP-Servers fest, bei dem die Suche beginnt. Standardmäßig ist dies der oberste Bereich der OpenSSO-Installationsbasis.
Jede beliebige DN-Komponente des subjectDN des Ausstellers kann zum Abrufen einer CRL von einem lokalen LDAP-Server verwendet werden. Es handelt sich um einen String mit einem einzigen Wert wie z. B. "cn". Alle Root CAs müssen dasselbe Suchattribut verwenden.
Das Online Certificate Status Protocol (OCSP) ermöglicht OpenSSO-Diensten, den (Widerruf-)Status eines bestimmten Zertifikats zu bestimmen. OCSP kann verwendet werden, um einige der Betriebsvoraussetzungen zu erfüllen, die darin bestehen, zeitnähere Widerrufinformationen bereitzustellen, als mit CRLs möglich ist. Außerdem können sie zum Abrufen weiterer Statusinformationen verwendet werden. Ein OCSP-Client gibt eine Statusanforderung an einen OCSP-Empfänger aus und wartet mit dem Akzeptieren des fraglichen Zertifikats, bis der Empfänger eine Antwort bereitstellt.
Mit diesem Attribut wird die OCSP-Prüfung aktiviert. Standardmäßig aktiviert.
Dieses Attribut definiert eine URL, die den Standort des OCSP-Empfängers angibt. Beispiel: http://ocsp.example.net:80.
Standardmäßig wird der Standort des OCSP-Empfängers implizit aus dem zu validierenden Zertifikat ermittelt. Die Eigenschaft wird verwendet, wenn die Erweiterung für den Zugriff auf Autoritätsinformationen (in RFC 3280 definiert) im Zertifikat fehlt oder überschrieben werden muss.
Das Pseudonym für den OCSP-Empfänger ist das Pseudonym des CA-Zertifikats für den betreffenden Empfänger, beispielsweise Certificate Manager - sun. Wenn dieses Attribut festgelegt ist, muss das CA-Zertifikat in der Zertifikatsdatenbank des Webservers vorgelegt werden. Wenn die OCSP-URL festgelegt ist, muss auch das Pseudonym des OCSP-Empfängers festgelegt sein. Anderenfalls werden beide ignoriert. Wenn sie nicht festgelegt sind, wird die im Zertifikat des Benutzers angegebene OCSP-Empfänger-URL für die OCSP-Validierung verwendet. Falls die OCSP-Empfänger-URL nicht im Zertifikat des Benutzers angegeben ist, wird keine OCSP-Validierung durchgeführt.
Laut Information Technology Management Reform Act (Public Law 104-106) genehmigt das US-amerikanische Handelsministerium Standards und Richtlinien, die vom National Institute of Standards and Technology (NIST) entwickelt wurden, für auf Bundesebene eingesetzte Computersysteme. Diese Standards und Richtlinien wurden vom NIST als Federal Information Processing Standards (FIPS) zur regierungsweiten Verwendung herausgegeben. NIST entwickelt FIPS, wenn es zwingende Anforderungen seitens der Bundesregierung gibt, wie beispielsweise in Bezug auf Sicherheit und Interoperabilität, und keine brauchbaren Branchenstandards oder -lösungen vorliegen.
Diese Eigenschaft kann "true" (wahr) oder "false" (falsch) sein. Alle Kryptographievorgänge werden nur dann im FIPS-konformen Modus ausgeführt, wenn die Eigenschaft "true" ("wahr") ist.