Autorisation
L'autorisation dans le profil 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 "Avez-vous le droit de faire ce que vous tentez de faire ?".
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 au profil 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 :

- Le contrôle d'autorisation a lieu lorsqu'une entité tente d'accéder à une ressource dans une application mise à disposition par le profil 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.
- 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 profil complet) qui ne reconnaissent pas le fichier server.xml.
- 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.
- 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.
- 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.
<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 le profil 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.
<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>