Terminologie de sécurité du WAS Portal d’IBM

L’authentification est le processus par lequel des utilisateurs s’identifient pour pouvoir accéder à un système, ici votre portail AFW. L’ID/mot de passe utilisateur est la méthode d’authentification la plus courante, mais AFW en accepte d’autres qui peuvent affiner l’accès de l’utilisateur final : single sign-on (SSO) via Enterprise Identity Mapping (EIM) d’IBM ou Windows Kerberos. Cet article ne couvre pas les méthodes d’authentification ; le terme n’est défini ici que pour le distinguer d’un autre terme souvent mal compris : autorisation.

Autorisation

Il est facile de confondre ce terme avec l’authentification, mais il est très différent. C’est plus généralement, le contrôle d’accès : limiter les actions d’un utilisateur autorisé d’après une stratégie spécifique, appelée droits d’accès. A la différence du contrôle d’accès WAS ou IBM i de plus haut niveau, ici, les choses contrôlées ne sont pas des objets ou des interfaces système, mais des ressources WAS Portal : pages spécifiques, URL, portlets, et interfaces administratives.

Droits d’accès

Comme indiqué dans le paragraphe précédent, un droit d’accès est une stratégie qui permet à un utilisateur d’accéder à une ressource dans un but bien précis et restreint, appelé opération sensible. Un droit d’accès peut être très simple : permission de voir une page Web, ou très complexe : exécuter des commandes administratives XML. La figure 2 récapitule les ressources AFW et les opérations sensibles qui constituent les droits d’accès disponibles.

Rôle

AFW fonctionne sous WAS Portal, et celui-ci utilise un concept de rôle pour combiner des droits d’accès et des ressources. Les rôles sont classés par types, avec des noms prédéfinis comme Administrator et User. Un ensemble de permissions prédéfinies est associé à chaque rôle. La figure 3 présente les types de rôles disponibles avec leurs permissions associées. AFW organise les rôles sous forme hiérarchique, chacun d’eux ayant toutes les permissions des règles au-dessous de lui. La figure 4 illustre cette hiérarchie.

Utilisateurs et groupes d’utilisateurs. Tous les concepts d’AFW précédents sont rassemblés sous la forme d’utilisateurs, qui représentent les utilisateurs finaux de votre portail. AFW authentifie les utilisateurs puis leur accorde des droits d’accès d’après les rôles et les autorisations que vous leurs octroyez. Vous organisez les utilisateurs en différents groupes pour simplifier la gestion des autorisations, avec tous les membres d’un groupe partageant un ou plusieurs rôles. Un utilisateur peut avoir plusieurs rôles : c’est pratique pour accorder et révoquer entièrement des ensembles de droits d’accès.

Héritage

Les ressources de WAS Portal sont organisées en une structure arborescente, dans laquelle les ressources de plus haut niveau « contiennent » celles de niveau inférieur. Par exemple, une page portail du menu principal peut pointer vers des pages de sous menus, lesquelles pointent vers d’autres pages. La hiérarchie des rôles dans cette structure arborescente permet de comprendre la somme des droits d’accès d’un utilisateur donné. Quand vous assignez un groupe à un rôle pour une ressource particulière, toutes les ressources subsidiaires héritent automatiquement de ces rôles et donc de leurs droits d’accès associés.

AFW

emploie une notation simple pour spécifier les combinaisons rôles et ressources, sous la forme role@resource. Par exemple, l’administrateur de tout un portail AFW pourrait être spécifié sous la forme Administrator@MyPortal. L’éditeur d’une page particulière dans ce portail pourrait être Editor@WarehousePage. Si WarehousePage a des pages subsidiaires, comme AtlantaWarehouse et ChicagoWarehouse, ces ressources héritent des attributions de rôle de la WarehousePage parente. Si le groupe d’utilisateurs Buyers a besoin d’un accès au niveau Editor à toutes les pages sous WarehousePage, il suffit d’attribuer à ce groupe le rôle Editor@WarehousePage. Tous les utilisateurs membres de ce groupe obtiennent les droits Editor sur les pages portail AtlantaWarehouse et ChicagoWarehouse.

Parfois, vous ne voudrez pas que l’héritage se propage aux ressources subsidiaires. Vous pouvez le faire avec un role block, qui empêche une ressource et ses subsidiaires d’hériter des rôles de ressources plus élevées dans l’arbre. Par exemple, si la page AtlantaAirport est sous la page Atlanta dans votre arbre de ressources, le fait d’ajouter un role block Editor à la page AtlantaAirport empêche le rôle Editor de se propager à cette page et à ses subsidiaires.

6 domaines clés à évaluer pour adopter la culture DevSecOps · iTPro.fr