Différences de configuration entre le profil complet et le profil Liberty : sécurité
Les différences de configuration de la capacité de sécurité entre le profil Liberty et le profil complet indiquent les éléments à connaître en cas de migration des applications.
La sécurité du profil Liberty ne prend en charge qu'un sous-ensemble de fonctions de sécurité du profil complet. A moins que le support ne soit mentionné explicitement dans la documentation du profil Liberty, il n'est pas encore disponible.
- Les API et SPI publiques ne sont pas toutes supportées. La documentation d'API Java™ pour chaque API de profil Liberty est détaillée dans la section Interfaces de programmation (API) du centre de documentation et est également disponible dans un fichier .zip distinct dans l'un des sous-répertoires javadoc du répertoire ${wlp.install.dir}/dev.
- Propagation horizontale
- Prise en charge du bean géré SecurityAdmin ; par conséquent, les méthodes telles que celles qui permettent de vider le cache d'authentification ne sont pas disponibles
- Support pour les modules de mappage du principal J2C (Java 2 Connector)
- Support des domaines de sécurité multiples
Vérification d'identité CSIv2 avec nom distinctif et chaîne de certificats.
Propagation des attributs de sécurité CSIv2 .
Authentification Kerberos.
SPNEGO sur kit Java Development Kit non IBM.
- Sous-système d'audit de sécurité dans l'infrastructure de sécurité du serveur
Dans le profil Liberty, vous pouvez configurer des mappages entre des utilisateurs et des rôles ainsi que des utilisateurs RunAs dans l'élément application-bnd qui figure dans le fichier server.xml. Dans le cas d'une entrée Run-As, le mot de passe est facultatif. Dans le profil complet, vous ne pouvez configurer l'entrée Run-As que dans le fichier ibm-application-bnd.xml/xmi. Dans le cas d'une entrée Run-As, le mot de passe est requis. Voir Configuration de l'autorisation pour les applications dans le profil Liberty.
Dans le profil Liberty, des noms de rôle peuvent être référencés par les API HttpServletRequest.isUserInRole et EJBContext.isCallerInRole ou par des éléments du descripteur de déploiement sans qu'il ne soit nécessaire de les déclarer d'abord avec l'annotation @DeclareRoles ou l'élément <security-role/> dans le descripteur de déploiement. Toutefois, les rôles doivent être déclarés avant d'être utilisés dans le profil complet.