Différences de configuration de la sécurité entre lWebSphere Application Server Traditional et Liberty
Les différences de configuration de la capacité de sécurité entre Liberty et WebSphere Application Server Traditional indiquent les éléments à connaître en cas de migration des applications.
La sécurité Liberty ne prend en charge qu'un sous-ensemble de fonctions de sécurité de WebSphere Application Server Traditional. A moins que la prise en charge ne soit mentionnée explicitement dans la documentation Liberty, vous devez supposer qu'elle n'est pas encore disponible.
- La sécurité Java™ 2.
- Les API et SPI publiques ne sont pas toutes supportées. La documentation d'API Java de chaque API Liberty est disponible dans un fichier .zip séparé 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
- Prise en charge des modules de mappage du principal J2C (Java 2 Connector)
- Prise en charge des domaines de sécurité multiples
- Sous-système d'audit de sécurité dans l'infrastructure de sécurité du serveur
- Délégation SAF
- L'autorisation SAF n'est pas possible avec un registre d'utilisateurs non situé sur le système d'exploitation local.
- Mappage des identités réparties aux ID SAF
Dans 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 WebSphere Application Server Traditional, 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 Liberty.
Dans 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 de les utiliser dans WebSphere Application Server Traditional.