Les attributs de sécurité définissent les informations de chiffrement, de validation et de cookie pour contrôler le niveau de sécurité de l'instance de serveur.
Les attributs de codage sont :
Spécifie la clé utilisée pour chiffrer et déchiffrer les mots de passe et est stocké dans la configuration du système de gestion des services. Cette valeur est définie pendant l'installation. Exemple : dSB9LkwPCSoXfIKHVMhIt3bKgibtsggd
Secret partagé du module d'authentification d'application. Cette valeur est définie pendant l'installation. Exemple : AQICPX9e1cxSxB2RSy1WG1+O4msWpt/6djZl
La valeur par défaut est com.iplanet.services.util.JCEEncryption. Spécifie l'implémentation de classe de chiffrement. Les classes disponibles sont com.iplanet.services.util.JCEEncryption et com.iplanet.services.util.JSSEncryption.
La valeur par défaut est com.iplanet.am.util.JSSSecureRandomFactoryImpl. Spécifie le nom de la classe de fabrique SecureRandomFactory. Les classes d'implémentation disponibles sont com.iplanet.am.util.JSSSecureRandomFactoryImpl qui utilise JSS, et com.iplanet.am.util.SecureRandomFactoryImpl qui utilise du code purement Java.
Les attributs de validation sont :
La valeur par défaut est 16384 ou 16k. Spécifie la longueur de contenu maximale de requête HttpRequest acceptée par OpenSSO.
La valeur par défaut est NO. Spécifie si l'adresse IP du client est vérifiée lors de chaque création ou validation de jetons SSOToken.
Les attributs de cookie sont :
La valeur par défaut est iPlanetDirectoryPro. Nom de cookie utilisé par le service d'authentification pour définir l'ID de gestionnaire de session valide. La valeur de ce nom de cookie est utilisée pour extraire les informations de session valides.
Permet au cookie OpenSSO d'être défini dans un mode sécurisé dans lequel le navigateur ne renvoie le cookie que si un protocole sécurisé tel que HTTP est utilisé. La valeur par défaut est false.
Cette propriété permet à OpenSSO de coder par URL (URLencode) la valeur de cookie qui convertit les caractères en caractères compréhensibles par le protocole HTTP.
Les attributs suivants vous permettent de configurer les informations de keystore des sites et serveurs supplémentaires que vous créez :
Cette valeur est définie pendant l'installation. Exemple : base OpenSSO/URI_serveur/keystore.jks. Spécifie le chemin du fichier de mots de passe de keystore XML SAML.
Cette valeur est définie pendant l'installation. Exemple : base OpenSSO/URI_serveur/.storepass. Spécifie le chemin du fichier storepass de clé XML SAML.
Cette valeur est définie pendant l'installation. Exemple : base OpenSSO/URI_serveur/.keypass Spécifie le chemin d'accès au fichier de mots de passe de clé XML SAML.
La valeur par défaut est test.
Ces attributs définissent le référentiel de mise en cache LRC (Liste de Révocation de Certificats) local utilisé pour conserver la LRC des autorités de certification. Un service devant obtenir une LRC en vue de la validation de certificat reçoit la LRC en fonction de ces informations.
Spécifie le nom du serveur LDAP sur lequel les certificats sont stockés. La valeur par défaut est le nom d'hôte spécifié lors de l'installation d'OpenSSO. Vous pouvez utiliser le nom d'hôte de tout serveur LDAP contenant les certificats.
Spécifie le numéro de port du serveur LDAP sur lequel les certificats sont stockés. La valeur par défaut est le port spécifié lors de l'installation d'OpenSSO. Vous pouvez utiliser le port de tout serveur LDAP contenant les certificats.
Indique si la fonction SSL doit être utilisée pour accéder au serveur LDAP. La valeur par défaut est que le service d'authentification de certificat n'utilise pas la fonction SSL pour l'accès LDAP.
Spécifie le DN de liaison dans le serveur LDAP.
Définit le mot de passe à utiliser pour établir la liaison avec le serveur LDAP. Par défaut, le mot de passe amldapuser entré lors de l'installation est utilisé comme utilisateur de liaison.
Cet attribut spécifie le DN de base utilisé par l'objet Utilisateurs LDAP dans le serveur LDAP à partir duquel commencer la recherche. Par défaut, il s'agit du domaine de niveau supérieur dans l'installation de base OpenSSO.
N'importe quel composant DN du subjectDN de l'émetteur peut être utilisé pour extraire une LRC d'un serveur LDAP local. Chaîne de valeur unique, telle que "cn". Tous les AC racine doivent utiliser le même attribut de recherche.
Le protocole OCSP (Online Certificate Status Protocol) permet aux services d'OpenSSO de déterminer l'état (révocation) d'un certificat spécifié. Le protocole OCSP peut être utilisé pour répondre à certains besoins opérationnels de fournir des informations de révocation plus rapidement que ne le permettent les LRC. Il peut aussi être utilisé pour obtenir des informations de statut supplémentaires. Un client OCSP émet une demande de statut vers un répondeur OCSP et suspend l'acceptation du certificat en question jusqu'à ce que le répondeur fournisse une réponse.
Cet attribut active la vérification OCSP. Il est activé par défaut.
Cet attribut définit une URL qui identifie l'emplacement du répondeur OCSP. Par exemple, http://ocsp.exemple.net:80.
Par défaut, l'emplacement du répondeur OCSP est déterminé implicitement à partir du certificat en cours de validation. La propriété est utilisée lorsque l'extension Authority Information Access (définie par RFC 3280) est absente du certificat ou lorsqu'elle doit être ignorée.
Le surnom du répondeur OCSP est le surnom du certificat d'AC de ce répondeur (par exemple, Certificate Manager - sun). Si cet attribut est défini, le certificat d'AC doit être présenté dans la base de données de certificats du serveur Web. Si l'URL OCSP est définie, le surnom du répondeur OCSP doit également être défini. Sinon, les deux sont ignorés. S'ils ne sont pas définis, l'URL du répondeur OCSP présentée dans le certificat de l'utilisateur est utilisée pour la validation OCSP. Si l'URL du répondeur OCSP n'est pas présentée dans le certificat de l'utilisateur, aucune validation OCSP n'a lieu.
Dans le cadre de la loi Information Technology Management Reform Act (Public Law 104-106), le ministre du commerce approuve les standards et les directives développés par le NIST (National Institute of Standards and Technology) pour les systèmes informatiques fédéraux. Ces standards et ces directives sont émis par le NIST en tant que standards FIPS (Federal Information Processing Standards) à utiliser au niveau du gouvernement. Le NIST développe des standards FIPS en cas de besoins impérieux du gouvernement fédéral (par exemple, en matière de sécurité et d'interopérabilité) et s'il n'existe aucune solution ou aucun standard industriel acceptable.
Cette propriété peut être true ou false. Toutes les opérations de chiffrement exécutent le mode compatible FIPS uniquement si la valeur est true.