Utilisation de rôles pour l’autorisation du client

Vous utilisez la sécurité basée sur les rôles pour établir une stratégie d’autorisation, en déterminant le ou les clients à laisser entrer et avec quelle autorité. Vous décidez qui doit être en mesure d’effectuer les actions et d’accéder aux ressources.

Les rôles facilitent cela en agissant comme un mécanisme de contrôle d’accès appelé chaque fois qu’un utilisateur tente d’accéder à une ressource d’application. Un rôle est essentiellement une liste d’utilisateurs, plus précisément une catégorie symbolique d’utilisateurs qui partagent le même privilège de sécurité. Lorsque vous attribuez un rôle à une ressource d’application, vous accordez l’autorisation d’accès pour cette ressource à quiconque est membre de ce rôle.

Par conséquent, vous pouvez définir un privilège de sécurité très particulier en le déclarant en tant que rôle, puis en l’affectant à des ressources spécifiques. Lorsque l’application est déployée, l’administrateur système peut remplir le rôle avec des utilisateurs et des groupes d’utilisateurs réels. Lorsque l’application s’exécute, COM+ applique la stratégie en effectuant des vérifications de rôle.

Fondamentalement, les rôles aident à protéger votre code, c’est-à-dire les méthodes qui peuvent être appelées par les clients d’une application COM+. L’appartenance au rôle est vérifiée chaque fois qu’un client tente d’appeler une méthode exposée par un composant dans une application. Si l’appelant est dans un rôle attribué à la méthode ou à la ressource appelée, l’appel réussit ; sinon, il échoue.

Sécurité Role-Based déclarative

Avec la sécurité déclarative basée sur les rôles, vous déclarez administrativement des rôles (à l’aide de l’outil d’administration Services de composants ou des fonctions d’administration) et vous les affectez administrativement aux ressources d’application. L’emplacement et la façon dont vous définissez la sécurité déclarative déterminent où les limites de sécurité sont établies pour votre application. Pour plus d’informations, consultez Limites de sécurité.

Vous pouvez attribuer un rôle donné à l’ensemble de l’application, à un composant particulier, à une interface particulière dans un composant ou à une méthode particulière sur une interface. Les attributions de rôles sont héritées dans la chaîne naturelle d’inclusion, autrement dit, si vous attribuez un rôle à un composant, il est implicitement attribué à chaque interface et méthode exposée par ce composant.

Grâce à la disponibilité des attributions de rôles au niveau de la méthode, vous pouvez efficacement protéger les composants et les interfaces qui n’ont pas été conçus en tenant compte de la sécurité. Toutefois, si les méthodes elles-mêmes ne sont pas sécurisables avec des attributions de rôles déclaratifs, vous devrez peut-être effectuer une vérification de rôle par programmation. Il est généralement judicieux de garder la sécurité à l’esprit lorsque vous décidez comment factoriser les fonctionnalités métier à l’aide de méthodes ; sinon, vous pourriez vous retrouver à ajouter du code lié à la sécurité à la dernière minute.

Pour obtenir des procédures détaillées pour définir la sécurité basée sur les rôles, consultez Configuration de la sécurité Role-Based.

Sécurité par programme

Dans certaines circonstances, vous pouvez placer la logique de sécurité dans les composants tout en utilisant la sécurité basée sur les rôles. Il se peut que vous ne soyez pas en mesure de prendre en compte toutes les décisions d’accès par le biais de méthodes ou que vous choisissez de ne pas le faire. Par exemple, vous pouvez avoir une ressource d’application privée, peut-être une base de données particulière, à laquelle vous souhaitez autoriser uniquement certains appelants d’une méthode à accéder tout en excluant d’autres. Vous pouvez également avoir une seule méthode TransferMoney et vouloir restreindre certains appelants en limitant le montant qu’ils peuvent transférer.

Dans de telles circonstances, vous pouvez vérifier le rôle dans le code. Une API simple est fournie, ce qui vous permet de case activée si la sécurité est activée et si un appelant ou un utilisateur particulier se trouve dans un rôle donné. Cette fonctionnalité n’est disponible que lorsque la sécurité basée sur le rôle est activée. Cela signifie que vous pouvez toujours tirer parti de la sécurité déclarative basée sur les rôles là où cela suffit, puis vous pouvez l’étendre par programmation à un niveau de granularité plus fin si nécessaire.

En outre, lorsque vous utilisez la sécurité basée sur les rôles, vous disposez d’un accès par programme aux informations relatives à tous les appelants amont dans la chaîne d’appels à votre composant. Cela est particulièrement utile lorsque vous souhaitez conserver une piste d’audit détaillée.

Pour obtenir des descriptions de la vérification des rôles dans le code et de l’accès aux informations de contexte des appels de sécurité, consultez Sécurité des composants programmatiques.

Autorisation et authentification

Une autorisation significative suppose que vous soyez sûr que les clients sont réellement qui ils disent qu’ils sont. La vérification de l’identité du client est gérée séparément par un service d’authentification. Sans authentification, vous laissez les appelants entrer sur le système d’honneur. Pour obtenir des descriptions de l’authentification qui a un impact sur les applications COM+, consultez Authentification client.

Rubriques connexes

Conception efficace des rôles

Limites de sécurité

Informations sur le contexte des appels de sécurité

Propriété de contexte de sécurité