SAP PAPA Shop User Guide

Size: px

Start display at page:

Download "SAP PAPA Shop User Guide"

Lauren Tucker
6 years ago
Views:

1 Norfolk Southern Corporation 1/15/2015

Background PAPA (Position Attribute Privilege Assignment) Shop is a web-based entitlement management system designed to facilitate the maintenance and monitoring of SAP access in an accurate,

SPOCs (Security Points Of Contact) have the ability to display and compare current access for employees and make requests where permitted to add or remove business roles and privileges.

2 Background PAPA (Position Attribute Privilege Assignment) Shop is a web-based entitlement management system designed to facilitate the maintenance and monitoring of SAP access in an accurate, efficient and well controlled manner. PAPA Shop is accessed via the SPOC tab in the Employee Resource Center (ERC). SPOCs (Security Points Of Contact) have the ability to display and compare current access for employees and make requests where permitted to add or remove business roles and privileges. There are also various reporting queries available to help identify the exact role(s) needed, including queries to track the progress of submitted requests. BROs (Business Role Owners) have the ability to view the full details of access requests and either approve or reject them in a UWL (Universal Work List) workflow integrated within the SAP enterprise portal. A single request can be routed to several different BROs depending on the roles being requested, and both primary and secondary BROs are included in the escalation process. 1 P a g e

3 Selection Criteria and Access Mapping Areas displaying and comparing user access 1. The Selection Criteria link expands or collapses the header fields used to enter the target user, model user, business role to modify, and explanation/justification for making the access request. If the header fields are collapsed, additional detail lines are displayed in the role mapping section. 2. The Additional Information link opens and closes the side panel of queries on the right. 3. The RACF ID of the target employee for whom access would be requested. 4. The PERNR of the target employee for whom access would be requested. 5. The HR position number of the target employee for whom access would be requested. 6. A display-only list of the attributes of the position currently occupied by the target user, or a vacant position if no RACF ID and PERNR is present. These attributes are used by assignment rules to determine which business roles and privileges a position should have. 7. The RACF ID of the model employee whose access is to be compared to that of the target employee. 8. The HR position number of the model employee whose access is to be compared to that of the target employee. 9. Name and job title of the target employee. 10. The Business Role number for which access is to be added to or removed from the target employee. When the Shop Now button is pressed, access details for this business role will become available in the Add / Remove tab, allowing the end user to view and/or modify access for the target employee. If the employee is already assigned the Business Role, the access shown represents what the employee currently has. Otherwise, the access shown is hypothetical that is, what the employee would inherit by being assigned the business role. 11. The Request Explanation window provides the end user a free text field to enter any justification information for the request that might assist the business role owner(s) in the approval process. 12. The Shop Now button will refresh the current access listing for the target employee (as well as the model employee if present). If a business role is present in the Role ID field, access details for this business role will become available in the Add / Remove tab. If a different target user has been entered, then the contents of the shopping cart will be cleared. 13. The Items in Shopping Cart link opens the shopping cart, which contains any business roles and/or privileges that have been added to the cart for the current target employee. Note that only one target employee can be processed at a time, and selecting a different target employee will cause the contents of the shopping cart to be lost. Multiple model employees can be used without affecting the cart, however. 2 P a g e

4 14. The Current Access Mapping tab displays the current production SAP access for the target employee (as well as the model employee, if present). Any differences between the target and model employees are marked in the Access column on the right. If both employees have the access, Both will be displayed. Otherwise, the word Target or Model will indicate which employee has the access. 15. The Add / Remove tab displays the access details for the selected Business Role and target employee and allows changes to be requested. The Business Role displayed will be either the role entered in the Role ID field, or if the Select Role for Action button is pressed, whichever business role was selected in the current access list. If the employee is already assigned the Business Role, the access shown represents what the employee currently has. Otherwise, the access shown is hypothetical that is, what the employee would inherit by being assigned the business role. 16. If a row in the detail list is selected, pressing the Select Role for Action button will display the details for the selected Business Role and target user, regardless of the value in the Role ID field. 17. If the row is a business role header row, this field will contain the Business role number. Otherwise, the field will contain the SAP privilege, also known as a system technical role. 18. The business name/description, or title of the business role. 19. The BRO (business role owner). 20. The SAP system ID for the privilege being displayed. 21. The Type or business role or privilege determines the ways it is permitted to be assigned to an employee. Type P (programmatic) implies the role or privilege can be assigned only automatically by satisfying a rule. Type PSL (Position Specific List) implies the role or privilege can be assigned only through a manual request. Type SP (semi-programmatic) can be assigned both automatically by satisfying a rule as well as by manual request. Note that if a rule is already satisfied, an SP type role or privilege cannot be manually requested for that particular employee. 22. The Assigned By Rule and Auto / Manual fields work together to describe in more detail how a role or privilege is assigned to the particular employee. If assigned by satisfying an automatic rule, the rule number that was satisfied by the employee s position will be displayed along with an A for automatic. Otherwise, the position number itself is displayed as the rule number and an M indicates the assignment was manually requested for the employee s position. Note that the internal contents of the rules themselves cannot be queried, although the end user will be able to query a verbal description of the rules. Security Administrators can provide details concerning the rule conditions if required. 23. The Access field indicates which employee (whether target or model) has the access being displayed, whether the Target only, the Model only or Both employees. 3 P a g e

5 Access Maintenance Screen requesting changes to user access This screen can be displayed by either clicking the Add / Remove tab or by selecting a detail line on the access mapping screen and clicking the Select Role for Action button. If no detail line has been selected for action, then the business role displayed here will be whatever value is in the Role ID field. The main purpose of this screen is to allow a SPOC to request a modification to the target employee s existing access concerning the desired business role. All privileges associated with the business role are displayed to provide a comprehensive overview, whether or not they are available to the position or are already assigned to the position. In order for the position to have actual access in SAP, it must qualify (by assignment rule) or be manually assigned BOTH the business role as well as a privilege. If only one or the other is true, then the position does not have actual access in SAP. For example, if the position is not currently assigned the business role, whatever privileges the position would qualify for are hypothetical that is, the position would receive the privileges only after it is assigned the business role. If a position qualifies for a business role or privilege by rule, the Qualifying Rule ID will display which assignment rule is satisfied. If role or privilege is manually assigned, the position number itself will appear in the Qualifying Rule ID field. The Auto / Manual field will also indicate whether there was a manual assignment. The following table describes how business roles and privileges work together to provide access to a position, either by satisfying assignment rules, by manual request, or a combination of each: Privileges Position is manually Business Roles assigned the privilege Position qualifies for the business role by assignment rule Position qualifies for the privilege by assignment rule Position is neither assigned nor qualifies for privilege ACCESS ACCESS NO ACCESS Position is manually assigned the business role ACCESS ACCESS NO ACCESS Position is neither assigned nor qualifies for business role NO ACCESS NO ACCESS NO ACCESS 4 P a g e

6 The Access Maintenance Screen can be used to make manual requests to either assign or remove the business role or privileges to/from the position, where permissible. This is done through the User Action drop down box by selecting either Assign or Remove. Manual requests can be used only to assign a role or privilege to a position, when permitted and where it does not already exist, or, remove a role or privilege, when permitted and where it does already exist. Only manual requests are possible the program logic can t change whether or not a position qualifies for a business role or privilege by assignment rule. Therefore, roles or privileges that must be provided only by assignment rule (type P ) cannot be assigned or removed. Likewise, if a position qualifies for an SP role or privilege by assignment rule, this role or privilege can t be removed. Should a SPOC wish to request such a business role or privilege, he or should contact the BRO to discuss the possibility of changing the assignment rules. It should be also noted that manual requests are permitted so long as the position will end up with both a business role as well as a privilege. The program will not allow a manual request to be made that leaves a position with a business role, but no privilege or vice versa. However, the program will assume that if a privilege is being requested that the business role is also being requested by default. 5 P a g e

7 1. The position already qualifies for this Business Role automatically by virtue of satisfying an assignment rule, specifically rule number 777. Therefore, the position will have actual access to any privileges for which the position also qualifies or has already been assigned from the displayed list. Since the position automatically qualifies for the business role, the program will not allow it to be removed through a manual request. 2. This is an example of a privilege whose assignment can be manually requested for the position. The position does not already qualify for the privilege by an assignment rule, and the privilege has not been previously assigned. 3. The privilege on this line has been previously assigned through manual request. It cannot be requested again. However, a request to remove the assignment is permitted, since there is no assignment rule that forces the privilege on the position. 4. This is an example of a fully programmatic type P privilege which cannot be manually requested. A position must qualify for such a privilege by assignment rule only, or not at all. Note that the program does not permit any User Action. 5. Type PSL privileges can only be manually requested there is no assignment rule that can provide the privilege to the position automatically. 6. We see here that the position automatically qualifies for type P and type SP privileges due to satisfying assignment rule number 257. The position obtains actual access to such privileges as long as the position also qualifies for or has been assigned the business role itself. Without being assigned the business role, this would be only hypothetical information for the position, showing the SPOC what the position would inherit should the business role be assigned. 7. Once the SPOC completes all user actions to assign or remove the business role and/or privileges, the desired requests can be added to the shopping cart by clicking Add to Cart. At this point, the SPOC may go back to the Current Access Mapping tab and select another business role for action without losing information in the cart. Once the cart is complete, the SPOC will click Items in Shopping Cart in order to submit the request. NOTE: Changing the target user will clear the shopping cart! The program is designed to make requests for a single user at a time. 6 P a g e

8 This screen illustrates a request to remove a manually assigned privilege and to manually assign a different privilege. The request has been added to the shopping cart. The contents of the shopping cart (below) are displayed by clicking the Items in Shopping Cart link (1). From here, the SPOC can remove the contents for a selected business role, or submit the request for business role owner approval. Once the request is submitted, the shopping cart is cleared. Click to remove from cart Click to submit Note that the business role is included in the cart, even though no assign or remove user action is being taken at the business role level itself. When privileges within the business role are involved in a request, but not the business role itself, the Action field will display Change. If the business role itself is being assigned or removed, the Action field would indicate that. 7 P a g e

9 If business role 125 were being assigned to the position, the Add / Remove tab would look like this: In the resulting shopping cart below, we can see that the business role itself is being manually requested. We can also see the privilege that is being manually requested from the previous screen. But note also that the shopping cart contains all other privileges for the business role that the position qualifies for by assignment rule. These privileges are displayed as information only to show the full extent of the access being assigned or removed. The Business Role Owners will not need to approve roles or privileges that a position qualifies for automatically by the rules that they themselves establish. The following are some additional sample scenarios for creating access requests: 8 P a g e

10 Note that a business role cannot be assigned without a privilege also being assigned. If the position had qualified for one of the two type P privileges by satisfying an assignment rule, then requesting this business role would have been permitted: When a privilege is requested, it is assumed that the business role is also being requested (if not already assigned and it is a type that can be requested). Here, Business Role 16 will be requested along with the privilege YEC_P2P_IM_MAT_WAREHOUSE.MEQ: 9 P a g e

11 In a similar scenario, we see that these type SP privileges cannot be manually requested, since the target position is not currently assigned Business Role 123: Even though this position qualifies for Business Role 123, it does not have actual access since it does not qualify for any privileges by assignment rules and no privileges have been manually assigned. Once one of the type SP privileges is requested, approved and assigned, the position will have access to Business Role 123: 10 P a g e

12 This screen shows that the position qualifies for a type P privilege within Business Role 192. The position does not have actual access, however, since it is not currently assigned the business role. Once the type PSL business role is manually assigned, access to the privilege will come automatically by virtue of the assignment rule: Workflow approving changes to user access Consider the example of a SPOC attempting to assign business role 125 to the following position: 11 P a g e

13 The shopping cart would contain the business role and privilege being manually requested as well as other privileges for which the position automatically qualifies by rule (as information only). Once the request is submitted for business role owner approval, only the role and privilege being manually requested will require approval. Once Create Request is clicked, it is assigned a request number: 12 P a g e

14 After submitting the request in the PAPA Shop, the SPOC will need to access NSCARS and select option 75, then select sub-option 2: After entering the PAPA Request ID the approval workflow and provisioning in the PAPA system will be initiated and generate an HPSM ticket automatically. Once the SPOC successfully submits a request, SAP Security is automatically notified that a pending request needs to be released. SAP must perform an analysis to identify any Segregation of Duties (SOD) violations prior to releasing the approval workflow. If the request can proceed, an SAP Security Administrator can release the workflow from their Universal Work List (UWL) using the screen below: 13 P a g e

15 After SAP Security releases the request, the business role approval workflow is initiated. For each BRO represented on the request, a workflow item is generated on the BRO s UWL. After 24 hours, the item is escalated to show up on the UWL of each secondary BRO as well. Once either of the two BROs (primary or secondary) processes the request, the item will drop off of both UWLs. If any part of a request is declined by the BRO, a notification is sent to the SPOC who made the request. Once all items on a request have been either approved or declined, the request will be provisioned automatically by the PAPA system at regular intervals (e.g. every 10 or 15 minutes). An approval task will look like this in a BRO s universal work list: 14 P a g e

16 Clicking the link will open up the details for the request that require approval from this particular BRO. The items can be approved or declined at the business role level or at the individual privilege level, where permitted. Approving or declining at the business role level will cause all privileges to follow suit unless overridden by the BRO: 15 P a g e

17 Note that only manual requests can be approved or declined, not roles or privileges that satisfy assignment rules. The program logic ensures that a BRO cannot modify the request in a way that leaves a business role without any assigned privileges, or a privilege without an assigned business role: A position that has a business role must also have at least one privilege. A position with at least one privilege must also have the business role. Otherwise, the program will display an error. The Reason text field permits the BRO to log a reason for the chosen action: After all items on the task have been approved or declined (or voided), the task will disappear from the BRO s workflow and be provisioned automatically by the PAPA system. 16 P a g e

18 Until then, the SPOC can track the progress of the request by using the SPOC Request query on the right side panel in the PAPA Shop: The following query will be displayed with complete details of the request and approval status so far for each BRO involved: SAP Security will be notified once every item on a request has been addressed by the required role owners. At that point, the request is confirmed and ready for provisioning. Once provisioned, the PAPA Shop will show the changes to the position s access: 17 P a g e

If any of the items were declined by a role owner, the requesting SPOC will receive an email notification.

can be performed to assist with the access assignment process. These queries use basic SAP Standard Reporting functionality.

19 If any of the items were declined by a role owner, the requesting SPOC will receive an notification. Side Panel User Queries In addition to the SPOC Request Query previously discussed, the side panel on the right of the PAPA Shop screen provides multiple queries that can be performed to assist with the access assignment process. These queries use basic SAP Standard Reporting functionality. The following are examples: The bar at the edge of the side panel can be clicked and dragged to change the size of the panel. A User Info query could be used to obtain the RACF ID of an employee in order to populate the target user field in the selection criteria area: 18 P a g e

20 The search result: You may click the plus sign to add additional rows to fine tune your search, as well as changing the middle dropdown from is to starts with or contains : BROs may wish to use the IDM Role Mapping query with 4999 as the Role ID to display a list of all Employees for any given day, or generally list people who have access to roles they own. The Export function can be used to load the data in Excel then sort, filter, and make decisions. 19 P a g e

21 Miscellaneous If no activity is detected for an extended period of time, the program will time out. If this occurs, refresh the browser to initiate the program once more. The error screen will appear like the following: When switching Target Users or Model Users, be sure and delete any Personnel No. and/or Position information lingering from the previously displayed employees, or the system will be unable to complete the search. 20 P a g e

TRAINING DOCUMENT Internet Expenses Administrator

TRAINING DOCUMENT Internet Expenses Author: William Arthur Green, Jr. Creation Date: March 26, 2007 Last Updated: September 28, 20 Control Number: Version: 1 Approvals: William Green Document Control Change