Authorization - resource and resource permission

Any request from application must be authorized to ensure that the current user has appropriate permissions to make the request.

Some sample requests are as follows:

Login page - A user does not require authorization to start the login page.
Login action - All users with a user name and password can log in to the application. The login action does not require specific authorization.
Home page - Requires authorization that is based on the Application Resource ID. If you have permission to access the application, you can load the home page.
Controller struts action - Specific permission is not required. However, permission check happens at individual mashup calls.
Mashup calls by using common controller struts action - Requires authorization, which is based on user's role.
Logout action - No permission required.

To enable the authorization for mashups, the resource permission method is used. All mashup definitions must be associated with at least one ResourceId, which implies that an open mashup call is not allowed. Mashups that are commonly used across the application must be associated with the ResourceId WSCSYS00001. An example mashup definition with ResourceId association is as follows (note the element AlternateResourceId(s) for association to ResourceId):

The following code snippet defines a mashup. This mashup is authorized if the current user has permission for any of the three ResourceIds mentioned in the 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>

UI Permission Check: Based on resource permissions, certain UI widgets are disabled or hidden. For example, the "Override Price" link in the Add Products screen is permission-controlled. Only if the user has the resource permission to override the price of the product, the link is visible in the UI. This is achieved by specifying an attribute resourceId and a corresponding value for the widget that must be permission-controlled.

Controlling the visibility of the widgets on the user interface is good from the usability perspective. However, this technique makes the application insecure because the hidden widgets can be made visible by manipulating the client-side response by using various tools or browser extensions like Firebug. Therefore, it is not sufficient to make the widgets (buttons or links) permission-controlled in the UI, but the action that is associated with the widget must also be permission-controlled in the backend. For example, it is not sufficient to hide the "Override Price" link in the UI, but the action that the link performs must also be associated with a permission check at the backend.

Resource permissions are assigned at the group level for users. System administrators and Sterling Store Engagement leads are assigned permissions to all tasks. However, a store associate is not assigned permissions to all the tasks.