Autorização-recurso e permissão de recurso

Qualquer solicitação do aplicativo deve estar autorizada para assegurar que o usuário atual tenha permissões apropriadas para fazer a solicitação..

Algumas solicitações de amostra são as seguintes:

Página de login-Um usuário não precisa de autorização para iniciar a página de login
Ação de login-Todos os usuários com nome de usuário e senha podem efetuar login no aplicativo. A ação de login não requer autorização específica..
Página inicial-Requer autorização com base no ID do Recurso do Aplicativo. Se você tiver permissão para acessar o aplicativo, será possível carregar a página inicial
Ação de struts do controlador-Permissão específica não é necessária No entanto, a verificação de permissão ocorre em chamadas de mashup individuais
Chamadas de mashup usando ação struts do controlador comum-Requer autorização, que é baseada na função do usuário.
Ação de logout-Nenhuma permissão é necessária

Para ativar a autorização para mashups, o método de permissão de recurso é usado Todas as definições de mashup devem estar associadas a pelo menos um ResourceId, o que implica que uma chamada de mashup aberta não é permitida Os mashups comumente utilizados em toda a aplicação devem estar associados ao ResourceId WSCSYS00001. Um exemplo de definição de mashup com ResourceId associação é o seguinte (observe o elemento AlternateResourceId(s) de associação a ResourceId):

O fragmento de código a seguir define um mashup. Esse mashup será autorizado se o usuário atual tiver permissão para qualquer um dos três ResourceIds mencionados no mashup

<?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>

Verificação de permissão da UI: com base nas permissões de recursos, determinados widgets da UI são desativados ou ocultos. Por exemplo, o link "Substituir preço" na tela Incluir produtos é controlado por permissão. Somente se o usuário tiver a permissão de recurso para substituir o preço do produto, o link estará visível na UI. Isso é alcançado especificando um atributo resourceId e um valor correspondente para o widget que deve ser controlado por permissão..

Controlar a visibilidade dos widgets na interface com o usuário é bom da perspectiva de usabilidade. No entanto, essa técnica torna o aplicativo inseguro porque os widgets ocultos podem ser visíveis manipulando a resposta do lado do cliente usando várias ferramentas ou extensões do navegador, como Firebug. Portanto, não é suficiente tornar os widgets (botões ou links) controlados por permissão na IU, mas a ação associada ao widget também deve ser controlada por permissão no backend. Por exemplo, não é suficiente ocultar o link "Substituir preço" na IU, mas a ação que o link executa também deve ser associada a uma verificação de permissão no backend.

As permissões de recursos são designadas no nível do grupo para usuários Administradores do sistema e oportunidades de vendas do Sterling Store Engagement são permissões designadas a todas as tarefas. No entanto, um associado da loja não recebe permissões para todas as tarefas.