Autorisation-ressource et droits d'accès aux ressources

Toute demande provenant de l'application doit être autorisée pour s'assurer que l'utilisateur en cours dispose des droits appropriés pour effectuer la demande.

Voici quelques exemples de demandes:

Page de connexion-Un utilisateur ne requiert pas d'autorisation pour démarrer la page de connexion.
Action de connexion-Tous les utilisateurs ayant un nom d'utilisateur et un mot de passe peuvent se connecter à l'application. L'action de connexion ne requiert pas d'autorisation spécifique.
Page d'accueil-Requiert une autorisation basée sur l'ID de ressource d'application. Si vous êtes autorisé à accéder à l'application, vous pouvez charger la page d'accueil.
Action Struts du contrôleur-Les droits spécifiques ne sont pas requis. Toutefois, la vérification des autorisations se produit lors des appels d'application composite individuels.
Appels Mashup à l'aide de l'action struts du contrôleur commun-Requiert l'autorisation, qui est basée sur le rôle de l'utilisateur.
Action de déconnexion-Aucune autorisation requise.

Pour activer l'autorisation pour les applications composites, la méthode des droits d'accès aux ressources est utilisée. Toutes les définitions d'application composite doivent être associées à au moins un ResourceId, ce qui implique qu'un appel d'application composite ouvert n'est pas autorisé. Les mashups couramment utilisés dans l'application doivent être associés au ResourceId WSCSYS00001. Voici un exemple de définition de mashup avec ResourceId une association (notez l'élément AlternateResourceId(s) pour l'association avec ResourceId) :

Le fragment de code suivant définit une application composite. Cette application composite est autorisée si l'utilisateur en cours dispose de droits pour l'un des trois ResourceIdmentionnés dans l'application composite.

<?xml version="1.0" encoding="UTF-8"?>
<mashups>
   <mashup cached="SESSION"
        description="Get List of Organizations applicable for current user"
        endpoint="EP_CONFIG" id="addItems_getOrganizationList"
        mashuptype="XAPI" transactional="true">
       <classInformation name="com.ibm.wsc.common.mashups.SCCSBaseMashup"/>
       <API Name="getOrganizationList">
           <Input>
               <Organization
                    DisplayLocalizedFieldInLocale="xml:CurrentUser:/User/@Localecode" MaximumRecords="">
                   <OrgRoleList>
                       <OrgRole RoleKey="ENTERPRISE"/>
                       <OrgRole RoleKey="SELLER"/>
                   </OrgRoleList>
                   <DataAccessFilter UserId="xml:CurrentUser:/User/@Loginid"/>
                   <OrderBy>
                       <Attribute Desc="N" Name="OrganizationName"/>
                   </OrderBy>
               </Organization>
           </Input>
           <Template>
               <OrganizationList>
                   <Organization CustomerMasterOrganizationCode=""
                        LocaleCode="" OrganizationCode="" OrganizationName="">
                       <BillingPersonInfo City="" Country="" ZipCode=""/>
                   </Organization>
               </OrganizationList>
           </Template>
       </API>
       <APINamespace inputNS="getOrganizationList_input" outputNS="getOrganizationList_output"/>
       <AlternateResourceIds>
            <AlternateResourceId altResourceId="WSCSYS00001"/>
            <AlternateResourceId altResourceId="WSC000006"/>
        </AlternateResourceIds>
   </mashup>
</mashups>

Vérification des droits d'interface utilisateur: en fonction des droits d'accès aux ressources, certains widgets d'interface utilisateur sont désactivés ou masqués. Par exemple, le lien "Prix de substitution" de l'écran Ajouter des produits est contrôlé par des droits d'accès. Le lien n'est visible dans l'interface utilisateur que si l'utilisateur dispose des droits de ressource permettant de remplacer le prix du produit. Pour ce faire, vous devez spécifier un attribut resourceId et une valeur correspondante pour le widget qui doit être contrôlé par des droits d'accès.

Le contrôle de la visibilité des widgets dans l'interface utilisateur est une bonne chose du point de vue de la convivialité. Toutefois, cette technique rend l'application non sécurisée car les widgets masqués peuvent être rendus visibles en manipulant la réponse côté client à l'aide de divers outils ou d'extensions de navigateur comme Firebug. Par conséquent, il ne suffit pas de contrôler les droits des widgets (boutons ou liens) dans l'interface utilisateur, mais l'action associée au widget doit également être contrôlée par des droits dans le système dorsal. Par exemple, il ne suffit pas de masquer le lien "Remplacer le prix" dans l'interface utilisateur, mais l'action effectuée par le lien doit également être associée à une vérification d'autorisation sur le système dorsal.

Les droits d'accès aux ressources sont affectés au niveau du groupe pour les utilisateurs. Les administrateurs système et les responsables Sterling Store Engagement se voient affecter des droits d'accès à toutes les tâches. Toutefois, un associé de magasin n'a pas de droits d'accès à toutes les tâches.