Liberty : Autorisation

L'autorisation dans Liberty détermine si un utilisateur peut accéder à un rôle donné sur le système.

L'autorisation spécifie les droits d'accès aux ressources. En général, elle suit l'authentification, qui confirme une identité. Alors que l'authentification répond à la question : "Etes-vous bien qui vous prétendez être ?", l'autorisation répond à la question répond à la question : "Etes-vous habilité à effectuer cette opération ?"

Autorisation d'accès aux fonctions administratives

Lorsqu'une entité tente d'accéder à une ressource, le service d'autorisation détermine si cette entité dispose des droits requis pour accéder à cette ressource. Ce principe est valable tant pour l'accès à une application que pour l'accès aux fonctions administratives. La principale différence entre ces deux types d'accès se situe dans la manière dont les utilisateurs sont mappés aux rôles. Pour l'autorisation d'accès à des applications, utilisez l'élément application-bnd dans le fichier server.xml ou le fichier ibm-application-bnd.xml/xmi pour mapper les utilisateurs à des rôles. Pour l'autorisation d'accès aux fonctions administratives, vous devez mapper les utilisateurs concernés au rôle d'administrateur en utilisant l'élément administrator-role dans le fichier server.xml. Pour plus d'informations sur la sécurité d'administration, voir Connexion à Liberty à l'aide de JMX.

Autorisation d'accès aux applications

Le diagramme suivant illustre le principe du mécanisme d'autorisation d'accès aux applications :

Figure 1. Vue d'ensemble du processus d'autorisation Le service d'autorisation vérifie les mappages des rôles et des utilisateurs dans les fichiers de configuration de l'application et du serveur, puis accepte ou rejette la demande d'accès.
  1. Le contrôle d'autorisation a lieu lorsqu'une entité tente d'accéder à une ressource dans une application mise à disposition par Liberty. Le conteneur Web appelle le service d'autorisation pour déterminer si un utilisateur a le droit d'accéder à une ressource particulière, compte tenu du ou des rôles requis. Les rôles requis sont déterminés par les éléments auth-constraint dans le descripteur de déploiement de l'application ou par les annotations @ServletSecurity dans le code source de l'application.
  2. Le service d'autorisation détermine à quels objets le rôle requis est mappé. Cette étape est effectuée par le traitement des mappages définis dans le fichier ibm-application-bnd.xmi ou le fichier ibm-application-bnd.xml, et l'élément application-bnd du fichier server.xml. Les mappages provenant de ces deux sources sont fusionnés. Si le même rôle est présent dans les deux sources, seul le mappage défini dans le fichier server.xml est utilisé. Lorsque les mappages entre rôles et utilisateurs, pour une application donnée, sont tous définis dans le fichier server.xml, l'application n'a pas besoin d'être conditionnée dans un fichier EAR et elle est plus simple à mettre à jour. L'utilisation du fichier ibm-application-bnd.xmi/xml a un intérêt si vous souhaitez rendre votre application portable vers d'autres serveurs (y compris vers le WebSphere Application Server Traditional) qui ne reconnaissent pas le fichier server.xml.
  3. Si le rôle requis est mappé au sujet spécial EVERYONE, le service d'autorisation rend immédiatement le contrôle pour que l'accès soit octroyé sans condition. Si le rôle est mappé au sujet spécial ALL_AUTHENTICATED_USERS et que l'utilisateur est authentifié, le service d'autorisation accorde l'accès à l'utilisateur. Si aucune de ces conditions n'est satisfaite, le service d'autorisation détermine quels utilisateurs et groupes sont mappés au rôle requis. Il accorde alors l'accès à la ressource si l'utilisateur est mappé au rôle requis ou s'il fait partie d'un groupe mappé au rôle requis.
  4. Le service d'autorisation renvoie un résultat au conteneur Web pour indiquer si l'accès est accepté ou refusé.

Sujets spéciaux

Lorsque vous mappez des entités à des rôles, vous pouvez mapper un sujet spécial à la place d'un utilisateur ou d'un groupe spécifique. Un sujet spécial est une extension du concept de sujet. Il représente un groupe d'utilisateurs d'une catégorie spécifique.

Les deux types suivants de sujet spécial sont disponibles :
  • EVERYONE : représente toute entité sur le système. La sécurité est inexistante car tous les utilisateurs sont autorisés à accéder à la ressource sans qu'il leur soit demandé de s'identifier.
  • ALL_AUTHENTICATED_USERS : représente toute entité ayant été préalablement authentifiée correctement auprès du serveur.
Pour mapper un sujet spécial à un utilisateur, mettez à jour le fichier ibm-application-bnd.xmi/xml ou le fichier server.xml. Dans cet exemple, le rôle nommé AllAuthenticated est mappé au sujet spécial ALL_AUTHENTICATED_USERS :
    <application-bnd>
           <security-role name="AllAuthenticated">
               <special-subject type="ALL_AUTHENTICATED_USERS" />
           </security-role>
       </application-bnd>

Voir Configuration de l'autorisation pour les applications dans Liberty.

ID d'accès et autorisation

Pour traiter l'autorisation d'un utilisateur ou d'un groupe, le serveur a besoin d'identifier sans équivoque cet utilisateur ou ce groupe. L'ID unique de chaque utilisateur ou groupe est utilisé à cet effet, ainsi que pour générer la configuration des autorisations. Ces ID sont déterminés par l'implémentation du registre d'utilisateurs : l'ID unique d'un utilisateur est la valeur renvoyée par l'appel getUniqueUserId(), tandis que l'ID unique d'un groupe est obtenu par getUniqueGroupId(). Vous pouvez aussi choisir de spécifier explicitement un ID d'accès pour un groupe ou un utilisateur dans la configuration des autorisations. Ces ID d'accès explicites sont utilisés à la place des valeurs renvoyées par l'implémentation du registre d'utilisateurs. Pour spécifier un ID d'accès dans le fichier ibm-application-bnd.xml/xmi ou dans le fichier server.xml, où l'élément application-bnd se trouve au-dessous de l'élément application, utilisez l'attribut access-id de l'élément user ou group.

Dans l'exemple suivant, un ID d'accès est spécifié pour l'utilisateur Bob et le groupe developers :
    <application-bnd>
           <security-role name="Employee">
               <user name="Bob" access-id="user:MyRealm/Bob"/>
               <group name="developers" access-id="group:myRealm/developers"/>
           </security-role>
    </application-bnd>
Remarque : L'attribut access-id est utilisé pour la vérification d'autorisation. S'il n'est pas spécifié, il est déterminé depuis le registre qui est configuré à l'aide du nom d'utilisateur ou de groupe. Toutefois, vous devez spécifier l'attribut access-id comme indiqué dans l'exemple, même si les utilisateurs ou groupes n'appartiennent pas au registre actif. Tout comme lorsque vous utilisez le Développement de modules de connexion de programmation pour Java Authentication et Authorization Service.

OAuth

OAuth est une norme ouverte de délégation d'autorisation. L'infrastructure d'autorisation OAuth permet à un utilisateur d'accorder à un tiers l'accès aux informations stockées avec un autre service HTTP sans partager ses droits d'accès ou la totalité des données. Pour plus d'informations sur l'utilisation d'OAuth pour les autorisations dans Liberty, reportez-vous à la documentation OAuth.

Autorisation pour les applications lorsqu'une liaison de mappage de rôle n'est pas fournie

Si les informations de liaison des mappages de rôles d'une application protégée ne sont pas fournies, le moteur d'autorisation par défaut utilise le nom de rôle qui protège la ressource en tant que nom de groupe associé à ce rôle. Par exemple, si le nom de rôle est manager, un utilisateur appartenant à un groupe de gestionnaires a accès à cette ressource. Ceci s'applique uniquement si aucune information de liaison d'application, dans le fichier server.xml ou le fichier de liaison d'application, n'est spécifiée pour l'application. Par exemple, l'ajout de cette liaison désactive la liaison du rôle de sécurité au groupe :
<application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
      <application-bnd>
	     <security-role name="anyAppRoleName"/>
      </application-bnd>
</application>
Remarque : Pour qu'une autorisation réussisse avec un nom de groupe dans le registre utilisateur, le nom de rôle doit correspondre au nom unique ou complet du groupe dans le registre qui est configuré et non au nom abrégé. Par exemple, si le nom abrégé du groupe est swGroup mais le nom unique ou complet figurant dans le registre utilisateur est CN=swGroup,o=company,c=us, vous devez spécifier CN=swGroup,o=company,c=us comme nom de rôle pour que l'autorisation réussisse.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_authorization
Nom du fichier : cwlp_authorization.html