Présentation rapide de la sécurité

Pour faciliter la compréhension du flux de travaux de base de la sécurité dans le profil Liberty, nous avons détaillé certains termes avec des exemples.

Termes clés relatifs à la sécurité

Authentification
L'authentification confirme l'identité d'un utilisateur. La forme la plus courante d'authentification est l'emploi d'un nom d'utilisateur et d'un mot de passe, comme pour l'authentification de base ou la connexion par formulaire pour les applications Web. Lorsqu'un utilisateur est authentifié, la source d'une demande est représentée en tant qu'objet Subject à l'exécution.
Autorisation
L'autorisation détermine si un utilisateur peut accéder à un rôle donné sur le système. Le modèle Java™ EE utilise des sujets, des rôles et des mappages de rôle afin de déterminer si l'accès est autorisé.
Rôle
Un rôle est défini dans l'application Java EE. Certains rôles, comme le rôle Administrateur, sont prédéfinis par le système. D'autres sont définis par le développeur d'applications. Dans Java EE, les sujets se voient généralement accorder ou refuser l'accès à un rôle en fonction des rôles qu'ils jouent dans l'application.
Sujet
Le terme sujet est employé à la fois dans un sens général et pour désigner un objet Java de la classe javax.security.auth.Subject (on parle alors d'objet Subject). Généralement, le terme sujet désigne toute entité active au sein du système. Il peut s'agir d'un utilisateur, mais aussi du processus système lui-même.

Exemple d'enchaînement d'activités de sécurité :

L'exemple suivant montre comment la sécurité est appliquée lorsqu'un utilisateur demande à accéder à une ressource. Ici, l'utilisateur Bob souhaite accéder à un servlet nommé myWebApp. Référez-vous aux exemples de code dans la rubrique Initiation à la sécurité dans le profil Liberty.

Pour que l'accès au servlet myWebApp soit possible, les conditions suivantes doivent être vérifiées :
  1. Bob est en mesure de se connecter au système, car le servlet est une ressource protégée.
  2. Bob a le rôle testing, car l'accès au servlet est restreint au moyen d'un élément auth-constraint dans le descripteur de déploiement du servlet en question.
Si Bob ne peut pas se connecter au système ou s'il n'a pas le rôle testing, l'accès au servlet myWebApp lui est refusé.

Un autre utilisateur, Alice, peut se connecter au système car il s'agit d'un utilisateur valide. Mais Alice n'a pas le rôle testing. Une erreur HTTP 403 (Accès refusé/interdit) s'affiche lorsqu'elle tente d'accéder au servlet.


Icône indiquant le type de rubrique Rubrique de référence

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=rwlp_sec_quick_overview
Nom du fichier : rwlp_sec_quick_overview.html