The purpose of this document is to summarise the technical solutions to custom-build your NWBC screens should you decide the SAP pre-delivered screens do not meet your requirements. The focus on this document applies to GRC 10.x Access Controls. However, some options apply to NWBC in general. This document does mention quite a few technical concepts (PFCG role menu for NWBC access, webdynpro, launchpads, etc). If you are not familiar with these concepts, I recommend you review available documentation in SCN and SAP Help. Technical implementation steps have not been included; however, links to other SCN blogs and Wiki where possible have been provided.

A Quick overview of the GRC SAP standard

In GRC 10.x Access Controls Work Center roles are provided by SAP to provide users with the NWBC layouts (each role provides a different tab). These roles are built based on PFCG Role menu using ABAP webdynpro GRFN_SERVICE_MAP with the specific application configuration mapped. Each folder name in the PFCG role provides the Level 1 Tab (such as Master Data, Access Request) and the webdynpro provides the layout for that tab. The individual links/icons are displayed based on configuration of a launchpad and authorisation object GRFN_REP (if the user does not have authorisations of the link in NWBC for that specific item they will not see it on their screen). Example role of this is SAP_GRC_NWBC as shown in the screen shot below with access to the the My Home, Rule Setup, Access Management and Reports and Analytics work centers.

          Screen Shot: example of SAP standard role that grants NWBC Work Center access for GRC

The idea of the GRFN_REP object allows you to reuse the launchpad to provide different links to different users (or if you are not using all of the functionality you can hide some from the users). However, lack of access to the authorisation does not guarantee the users has been prevented from accessing the functionality (if they know the SICF service name they can enter the URL assuming SICF has not been restricted with S_ICF authorisation).

  The launchpads can be customised to add/remove the SAP standard proposed links. Launchpad functionality does allow you to compare your changes to the SAP standard version. For information on GRC example, refer to the following document by Trinadh Bokka

I did not like the SAP standard work centers outside of prototyping/demonstration for the following reasons:

1. Having to assign the user multiple work centers to get their full access;
2. User having to jump across multiple tabs (Org Structure on one, Access Control Owners on another, risk and mitigation split up, etc);
3. Wanting to set up custom work center layouts as per the process steps (much more user friendlier); and
4. Old school’ avoidance to maintaining SAP standard (although possible, I am not a fan of maintaining the SAP launchpads as I like to have the original reference and not have headache at support packs/enhancement packs). Happy for someone to come along and convince me otherwise (a SAP Basis expert managed to convince me to stop building Custom ZSAP* work center roles for Solution Manager).

Hence, time to provide options on how you can build your own layout for users:

Option 1 – Standard NWBC Build

In this option you build your PFCG role menu without using the GRC Work Center concept. Refer to SAP help documentation for how to achieve this. Each link (webdynpro) must be added to the PFCG role menu as a link and configured to appear in NWBC. This option does allow you to add different levels of folders and group the links together. It provides you the greatest control in choosing what you want to display in the SAPGUI menu and/or NWBC menu. It does not leverage the GRC launchpads or GRFN_SERVICE_MAP.

One benefit of this option is that by adding the webdynpro to the role menu you can leverage the SU24 mapping proposals. At the same time, you will need to go through and figure out the defaults for each webdynpro as SAP did not deliver any standard SU24 proposals (it takes time but is worth it when it comes to security build and testing).

You will, however, need to build PFCG role menu for each access scenario instead of re-use of the work center roles and launchpads. This may not be a drawback for you if your PFCG role is also including the underlying authorisations to execute the functionality.

    Screen Shot: Building custom PFCG menu for NWBC layout

Option 2 – Use the Launchpad Webdynpro

Instead of using GRFN_SERVICE_MAP you can create the NWBC layout by adding the webdynpro APB_LAUNCHPAD_NWBC to the PFCG role menu. As part of the configuration parameters, you must specify the launchpad instance and role name.

     Screen Shot: Launchpad added to PFCG via APB_LAUNCHPAD_NWBC

This approach does not use the SAP delivered GRFN_SERVICE_MAP (and therefore hiding of links in NWBC via authorisation object GRFN_REP object). It also does not include each webdynpro link in the role menu to import the SU24 proposals (again assuming they exist). I had this as a solution on my options after looking at this webdynpro for an ECC build. However, I did not like that it provided the use with the option in NWBC to “change launchpad” as the user would be presented with the full list of launchpads to choose another.

      Screen Shot: Change Launchpad button for APB_LAUNCHPAD_NWBC

Option 3 – Build your own configuration for GRFN_SERVICE_MAP

In this option, you follow the SAP GRC work center approach by using GRFN_SERVICE_MAP to build your own launchpads and use them instead. Unlike the APB_LAUNCHPAD_NWBC, the PFCG item definition does not reference the role and instance. This is configured in the webdynpro configuration via SE80.

The diagram below provides the mappings of the webdynpro configuration and applications for GRFN_SERVICE_MAP. You will need to have a developer key to do this - or you may need to ask a developer depending on your company's policy. You will not need to register an SAP object in the Marketplace. If you receive a prompt of the object repair key you have attempted to modify the standard instead of copying your own.

     Diagram: Mapping of Webdynpro Configuration for GRFN_SERVICE_MAP

You will need to access SE80 for the GRFN_SERVICE_MAP and launch the Webdynpro Application Configurator (a link appears). To create your own, you need to copy the GRAC_FPM* items listed in the example and map them to each other. You are not modifying SAP standard. The “UIBB” item contains the link to the launchpad instance and role. The “AC” item is added to the PFCG menu for the GRFN_SERVICE_MAP.

My tip for copying these items: stick to a naming convention such as ZGRAC_FPM* to denote custom, use the AC/CC/UIBB (marked in red) and have the last character (example above ACCESS_MGMT) reflect the launchpad name. It becomes a lot easier to trace your configuration if you have a build error.

     Screen Shot: UIBB Configuration showing mapping to launchpad

This option allows you to leverage the GRC NWBC design and continue to use launchpad. It also means you do not need to maintain the SAP standard launchpad and can build your own.

Refer to the following Wiki article for the SE80 webdynpro configuration.

Option 3 Extended to leverage SU24 proposals

Each webdynpro referenced in the launchpad can also be added to the PFCG role menu but kept invisible. In doing this, SU24 proposal can then be defaulted into PFCG. This option will require dual maintanance of the launchpad and the PFCG menu.

Interested in Option 3… and more?

If the SAP standard roles are not appropriate for you, I recommend you have a look at the Option 3 mappings. Have a look at the PFCG role menu to see differences in making links invisible and changing the icons that you see in NWBC. You can also have a look in the SE80 configuration to change the Launchpad headings from hyperlink to plain bold text; see if you can find the default empty launchpad that has been mapped to all work centers; and work out why your are limited to two columns in your launchpad.

I welcome your constructive feedback in the comments below J

Regards

Colleen

This document is a collection of the most useful SAP GRC Access Control documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Processes, Lifecycles and Responsibilities

General opinion and thought-leadership

Are you ready to implement GRC 10?

A lot of help from my friends

If I had it to do all over: looking back on GRC 10 projects

Lessons learned from SAP GRC projects

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

GRC General

NWBC screen layout options for GRC

Customizing NWBC for New Menus with our own Transactions, Reports and Accessing SAP Backend Systems from NWBC

Configure LaunchPad for Menus

Access Risk Analysis (ARA)

Rule set - Rules & Rule Types

Business Risks / Rule Set

How to set up a Configurable Business Rule

Online vs. Offline Risk Analysis

Creation of Mitigation Controls in GRC 10.0

Organizational Rules in GRC Access Control

Mass change of Mitigation Assignments

SAP GRC AC 10.0 Alerting

Access Request Management (ARM)

MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls

Approve/Reject Own Requests

How to Change Subject Line in SAP GRC Email notification

Recommendations for using Business roles provisioning in access request

Business Role Management (BRM)

Maintain Default Roles in BRM GRC AC 10.1

Role Import - GRC 10

Import Role from ECC to GRC system

Emergency Access Management (EAM)

EAM - Provisioning Strategies

AC 10.0 - Centralized Emergency Access

Configure Emergency Access (EAM) in GRC 10

De-centralized EAM GRC 10.0

EAM - Approve through Wrokflow

Emergency Access Management Reporting

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro

Purpose

The purpose of this document is to provide a list of the top ten most viewed SAP KBA's for GRC Process Controls in the month of July 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Controls.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Related Content

Top 10 most viewed SAP KBA's for GRC Process Control in June 2014

Top 10 most viewed SAP KBA's for GRC Process Control in May 2014

Top 10 most viewed SAP KBA's for GRC Process Control in April 2014

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBA's for GRC Access Controls in the month of July 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Access Controls.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Related Content

Top 10 most viewed SAP KBAs for GRC Access Control in June 2014

Top 10 most viewed SAP KBAs for GRC Access Control in May 2014

Top 10 most viewed SAP KBAs for GRC Access Control in April 2014

GRC's Access Risk Analysis is a tool within Access Controls to enable you to define user access risk (via way of a rule set); execute risk analysis to identify access risk (or simulate for potential risk); and then provide you with system functionality to remediate the risk or mitigate via assignment of a control. As this is an approach, it can apply to any version of GRC (of course the system screen shots are in 10.x version).

Like any other risk process the reviewer is has four options: accept; transfer; mitigate or remediate. This document details our strategy and approach to risk remediation. Our position is that you should always attempt to remediate a risk before your mitigate. Remediation removes the risk (or the residual level is acceptable) from the system and does not rely on the use of compensating control (typically manual control that requires a person to take regular action and can be subjected to human error). Accepting and transferring of risk are last resorts. Of-course the your decision would involve a cost-benefit analysis. It makes not sense to spend more on the control than the true cost of the risk (financial, reputation, legal and compliance, etc).

When a risk has been identified (violation, issue, etc.) someone has to take action to resolve it. Depending on your master data setup, GRC automatically displays the risk definition, including who is responsible (risk owner); the respective business process; as well as mitigation owners/monitors. This information is important to enable your to know who to contact to discuss the risk and receive advise (and some of this interaction will occur off system).

Risk Violation Count is Massive (Why?)

Be aware that the first time you run a risk analysis it is likely that the number of violations will be very high. Users may have access creep due to change in job function and retained old access. Roles may have been built with too much access. At the time, the business did not have adequate tools to identify these risks. Many organisations undergo a security redesign project once they have implemented GRC due to the number of inherent conflicts in their roles. In the end they find it easier to completely rebuild security (get it right and clean first time) than try to unpick the issues and clean the existing roles. In some cases, companies are aware of the issues but mistakenly believe implementing GRC will fix it: all GRC will do is give you the number of violations and will not help you if you do not go down the path of remediation and mitigation.

For example, in the screen shot below there are over 200,000 conflicts (more if we scrolled down). This number is large - huge - and probably daunting when it comes to fixing it. After all where would you start? Remember a risk violation is one rule in the risk definition being met. Therefore, if a risk has two functions and both functions have two actions you then have 4 rule violations. If a user happens to have all four actions they too have 4 violations. If there are 50 derived roles, you will see the violation count increase to 200 (4 x 200). In the screen shot below, on further analysis (not visible in this screen shot) the bulk of the issues are caused by derived roles. By cleaning the imparting roles the number of violations will reduce substantially (also, you cannot clean a derived role without using PFCG incorrectly or actually fixing the imparting role).

Where to start for Remediation (Still overwhelmed by so many violations)?

Your security role design as well as access provisioning strategies will impact how you approach remediation. This diagram below assumed position-based security is used in your organisation. Depending on the authorisation concept and access management in your system, the number of circles will vary. For example, you may not user business roles or composite roles.

When approaching risk remediation, use the diagram below as a reference and work your way from the inside out.

1. Single Roles: focus on remediating conflict in your imparting roles and other non-derived single roles. You will fix the derived roles when you distribute the change from the imparting (assuming you have followed SAP standard security rules and not added additional authorisations to your derived). Single role clean up will involved removal of transactions and other authorisations.
2. Composite Roles: by this stage you expect that none of the single roles have inherent conflict. You cannot remediate risk in a composite role if the single role has conflict. Your choice to remediate at this point is to remove roles assigned to the composite (possible replace with a different version). Another option is to remove access from the single (it may not cause an inherent conflict in the single) if the access is not required and it is contributing to the violation.
3. Business Roles: this assumes you have built business roles via GRC Business Role Management for provisioning. Same principal applies as composite.
4. Positions: if you are using position based security then you can consider removing roles (single, derived, composite, etc) from the position.
5. Users: finally you have removed all inherited risk. The only unmitigated risk violations against the user is due to the combination of access. At this stage you can then remove roles.

Note: Remediating inherent role conflict will take time. You will need to work with the business process owners (the business) to determine the appropriate solution. Once you identify the permissions to removal from a role you will then need to follow your companies change management process to schedule the change and arrange a transport to Production. As an interim measure, you may need to implement a mitigating control.

Who should I engage with? What should I say?

This will depend on your company's organisational model and approach to risk management. However, regardless of approach it is still a business decision. You will need to consider meeting with the business process owners, line managers, etc.

In starting the conversation with these stakeholders you need to outline and explain what the risk is and why it needs to be remediated. In some cases the conversation may be as simple as 'Is this access really required'. You may discover over time that access creep has cause the conflict and requires clean-up. Where a user is concerned, the question may be 'Does this user really need both access'. The stakeholders identify non-compliance in a job duties or that there is an alternative person to take on part of the function. Again, it will all depend on the business so get out there and talk to the stakeholders!

For some more ideas refer to Reviewing of Risks in the: Risk Lifecycle

How can I decide remediation approach?

The diagram below has been devised to visually represent the process to deciding how to remediate the access. You may devise a similar approach and change the sequence of options depending on your organisation's policy.

Is it a Risk?: Before investing work effort into remediation you need to verify that violation is actually a risk and not a false positive.You may have executed the report at Action level only but if you re-ran at permission the violation is not longer there. Alternatively, you may look at the violation and question why it is a risk in the first place. If you realise the risk definition is incorrect then you need to change it. The rule-set (Business Risks / Rule Set) is not static and must be reviewed regularly.

Does the object need both functions?

The violation is a risk and you need to take action. Does the object (role, position, etc) require both actions? To assist in this decision you could look at action usage reports in GRC. If it appears one of the functions is not used, then remove it. For roles this will be a change request and users/positions it will be an Access Request. Approval from the business will be required regardless.

Is there Alternative Access?

You determined the both functions were used but could you assign a different transaction or authorisation combination to restrict. For example, the user might have XK01/02 transactions for Vendors but does not need all views - such as payments details. Instead they only need FK01/02 which does not include the payment details.  By changing the transaction over the user can still perform their job function via a different transaction.

Is there a System Control - Can system controls via IMG configuration, workflow and ABAP development be implemented to remove the risk? Alternatively, can the business process be changed to include a new step. For example, add vendor confirmation via FK08/FL09 for sensitive fields to force a second pair of eyes to review the change.

Unable to Remediate -  By this stage you have exhausted all possibilities to remediate the access and must investigate mitigation as an option.As already mentioned many times on SCN, always try to find a way to remediate a risk instead of defining compensating controls. Mitigation, whether it be with the help of spot checks, reviewing postings, etc. is always a reactive way and fraudulent actions might be done in the mean time. Still there needs to be a balance between managing risk and allowing the business to function. If you cannot remediate, refer to the document for further details on defining mitigating controls: Defining Mitigating Controls / Compensating Controls

Analyse Again (or verify your Remediation via Simulation)

Once you have remediated your risk we recommend you re-execute your risks analysis. You need to ensure that by remediating the list violations you did not introduce a new one. The good news with GRC is the ability to simulate access risk. Before going to the effort of role change or access change you can execute a risk simulation to test removing of the conflicting function and replacing with the alternative. This will provide you with confidence to remediate and avoid introduction of new risk. Using simulation will also reduce rework through continual rebuild or access change.

Finally I'm Finished - the system is clean...

Sorry to break it to you bust risk identification and analysis is continual. You must regularly plan to review your rule set to ensure the risks are valid (support packs, enhancement packs, custom development, changes to configuration, changes to the business, etc) as the system and business is in a constant state of change. In addition, when security role changes are migrated to production then user may now have risks.

Keep on top of the review so you only ever have a small number of violations to respond to. Scheduling Role Re-certification in BRM, SoD and UAR Review workflow will help manage this regular review.

Does your organisation approach remediation in GRC differently? We would love to hear your feedback in the comments below.

Best regards,

Alessandro Banzer& Colleen Lee

Hi GRC space members

Participating in GRC with an attitude of continually giving to occasionally receive benefits us all. By voluntarily contributing to our space we all benefit in receiving technical document, strategies and ideas on how to architect, implement and support our systems. If you have been around this space for a while you might have noticed a slight increase in the volume and variety of documents and blogs being produced. What is fantastic about this is the number of authors involved. It is great to see the diversity of people contributing to our space. We want to see our space continue to grow and improve quality at the same time!

You may have noticed us starting to collaborate on articles or providing public feedback. Over time we have exchanged ideas and a vision on how we would like to see this space evolve. We also acknowledge we have different strengths and experiences and by teaming up we could improve our own quality and knowledge. The best improvement we felt was to encourage others to start producing material that was beyond the technical "How To" since these types of documents really belong in the Wiki (fingers crossed one day SAP/GRC Wiki will let some of us contribute there).

The idea - this idea - is a community collaborative effort to suggest topic ideas and for others to volunteer to write them. You might be out there wanting to contribute but cannot think of a topic (how many times has an article been published to which you realise you could have written something similar?) Perhaps you have searched looking for material for a specific question but could not locate it in help.sap, Marketplace, Wiki or SCN. Or maybe you have an idea for a topic but do not have the knowledge or experience to write it. All of these scenarios are what we want to target here.

Any SCN member can participate in this project:  GRC Document Collaboration Topics

You have an Idea for a Blog or Document:

• Search to see if it already exist - look in help.sap, Wiki. Remember we do not want duplicated material on SCN
• Edit the document GRC Document Collaboration Topics and add a row to the top of the table with a title and summary of your idea
• We encourage you to use your real name in your account to keep this professional
• Save and publish the document to make it available to the rest of the community

You want to volunteer to write the Blog or Document

• Ask yourself honestly if you are qualified/knowledgeable to attempt this (we want quality after all)
• We encourage you to use your real name in your account to keep this professional
• Edit the document GRC Document Collaboration Topics
• Write the document or blog as you intended to. Refer to the following SCN pieces for guidance:
  • The SCN Rules of Engagement - Moderators will reject content that is against the copyright and any other rules
  • Create a Blog Post
  • Create a Document
  • The Difference between a Discussion, Blog Post, Document and Wiki
  • You must acknowledge the person who suggested the topic and any collaboration you received
• Publish it
  • Please mention the person who provided the topic idea
• Update the document to show you have completed it GRC Document Collaboration Topics

As part of offering to be the author, you can ask for assistance. We felt this is a way for those new to blogging and writing documents to start. You might ask for help to review your document or provide input and feedback. You may be completely fine and require no assistance so good luck to you!

Note: if you promise to deliver by a certain date but do not complete you activity, we will attempt to follow up with you. If we cannot contact you with new deadline then we will remove your name for someone else to attempt the topic. Please consider your commitments before volunteering to attempt a topic. If you are aware you cannot meet the deadline but are still committed to writing it, please edit the document with an updated deadline.

Moderator and Coordinator Override

• If we are aware this topic is duplicate (i.e. covered already or exists in Wiki) then we will edit the document to "reject" it. We will add a reference to it
• If the promised deadline passes for a document or blog we will remove the author for let someone else have an opportunity
• Moderators are welcome to override any content they feel necessary
• Attempts will be made to privately contact the authors, etc to communicate reasoning and prevent wasting time and effort

You 'just' want to consume

Producing this type of content may not be your strength or interest and that is fine - there is no point writing something if we have no readers. Your contribution is import to this project by reading the material; liking the article (if you do); rating the article (if valid, poor ratings are encouraged but please add constructive feedback); and adding comments with your feedback. Rating and comments are an integral feedback mechanism to the author to help them improve their skills, and to the rest of the community to benefit from the article. At the same time if you change your mind or see a topic that you could attempt then by all means jump in and have a go!

So without further delay let's get blogging and writing! If you have any suggestions or clarifications please add comments to this blog below. We can update the guidelines based on feedback. Refer to the instructions below our sign-off for rules on participating.

Your SCN GRC self-proclaimed coordinators of this project (a mixture of SAP Mentors, Moderators and GRC enthusiasts):

Colleen Lee, Alessandro Banzer, Fernando Bassuino

Gretchen Lindquist and Frank Koehntopp

Instructions for updating the table in the document:

These are the instructions to update the document: GRC Document Collaboration Topics. If you would like to suggest improvements to the process or have any concerns, please add comments to this document. Based on community feedback, we can amend the rules if necessary.

Note: you are welcome to be both the Requester and the Author if you want to advertise that you are working on a topic

Step 1: Requester to Complete

1. Enter Date you added your entry
2. Add your name (remember copy URL or your profile and SCN will convert to your name)
3. Specify if it is a document or a blog
4. Idea - summarise what your idea is. Please advise if you would like overview, details, technical, etc. The author will take this as a consideration
5. Option - if the author follows you in SCN, recommend you follow them back so you can both communicate privately via SCN

Step 2: Author to Complete

1. Add your SCN profile to the document (remember copy URL of your profile and SCN will covert to your name)
2. Enter Date Due for when you intend to complete the document or blog. This is a self-imposed deadline. Refer to document link for rules to explain consequence if you cannot deliver in time. If deadline is close to approaching and you need time, please edit and extend deadline (within reason) to communicate you have prioritised it
3. Assistance - please advise if you would like someone to help you in writing your blog or document. Help can include contributing content and business examples or assistance with formatting and language. It may be your first time writing a professional document and you would like constructive feedback before publishing (it can be a bit scary posting your first document or blog).
4. Optional - recommend you follow the Requester in SCN to seek any further clarification and ideas (they will need to follow you back)

Step 3: Collaborator to complete (if assistance requested)

1. Add your SCN profile to the document (remember copy URL or your profile and SCN will convert to your name)
2. Follow the author on SCN so you can direct message each other

Step 4: Author to Publish

1. Add the link to the document or blog once completed
2. Ensure you document and blog acknowledges the person who suggested the idea and any collaboration you received.

Moderator and Coordinator Override

Moderators and those involved in SAP Wiki cleanup project may intervene and reject the topic idea. They must add their name and high level reason. They should reach out to the author to discuss reason for rejecting the suggestion. This moderator override has been included to reduce wasted effort or risk of rejected content via Alert Moderator functionality.

The coordinators of this project will intervene if the author does not meet their deadline commitments. They will add a comment if they have removed the author, etc. As most coordinators are not moderators (in the GRC space), they will perform more administrative functions of this project.

Happy brainstorming!

Hi All

If you are wondering what this document is all about then please refer to: Community Collaboration for GRC Blogs and Documents - you will find an overview of what this community collaboration is about and the rules on how you can contribute. You are still encouraged to write your own blogs and documents without participating in this process (it would be nice if you could update this document to let the community know you are working on something).

You are also welcome to be both the person who suggests the topic and the author. This can advertise you are working on the topic and hold yourself accountable to a deadline that the community is aware of.

Remember: Add a row below the 3rd row of the table to included your suggestion. Please do not change the first three heading rows as these rows indicate the title and a short summary of the content below. When including your name, please include your SCN profile as a hyperlink (easiest way to open your Profile in a new browser tab and copy the URL)

G’Day All,

Considering the fact that so many people out here, have so selflessly shared their expertise through blogs, answers etc. So its only fair that I do my bit to balance the scales. Now if what I contribute is worth it or not, that's a different story and I shall leave it to the moderators to judge for themselves.

The topic I would like to present to you is ARA. Just a heads up that whatever is presented here is just an overview of my understanding of what ARA is (from what I read here and SAP documentation) and how it works. I’ll leave it to the experts here to make corrections/suggestions if the need be for the benefit of everyone reading this document and myself included.

A lot of the key terminology has been explained rather brilliantly by Alessandro in the following two documents, so there is no point in me trying to reinvent the wheel.

http://scn.sap.com/docs/DOC-54434

http://scn.sap.com/docs/DOC-54530

So here we go.

This entire process is termed as 'SOD Management Process'.

Segregation of Duties (SoD) is an internal control within a Company implemented to prevent or decrease the risk of errors or regulatory irregularities and ensure corrective action is taken. Ideally, no one individual must have the authority of:

Creation . Modification . Reviewing . Deletion

SoD ensures no single user has access to separate phases of these business transactions. This is done by Dividing, Distributing and Allocating key tasks amongst various individuals thereby eliminating or at least reducing the possibility of errors and fraud.

All of this is carried out in three separate phases:

Phase 1

Risk Recognition

Rule Building & Validation

Phase 2

Risk Analysis

Remediation

Mitigation

Phase 3

Continuous Compliance

*Credit for the following SOD Management Process flow goes to: Alessandro& Colleen

Steps	Description
	Gather a list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation.   Helpful documents: Risk Lifecycle
	Build the rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set to analyze the user and/or role assignments.   Helpful documents: Business Risks / Rule Set Rule set - Rules & Rule Types
	Analyze the SoD output. This can be performed with the help of SAP GRC Access Control. In case of manual analysis, for each user, analyze if he/she has the access to perform any of the conflicting functions defined in step 1. The outcome is basically to provide the business insight to alternatives for correcting or eliminating discovered risks.   Helpful documents: Online vs. Offline Risk Analysis
	In this step, evaluate if the conflicting tasks can be performed by an alternate person. If so, role changes and/or user reassignments can be performed to segregate duties properly. The outcome must be a very low number of remaining risks that need mitigation.   Helpful documents: Remediating Access Control SoD Risks
	If it would not be possible to remediate the existing conflicts, consider formulating an appropriate control to mitigate the risk. This would typically entail working with the business to setup additional monitoring procedures that ensure to compensate the risk. The outcome must be no remaining risks.   Helpful documents: Internal Controls - a step towards strong controls Defining Mitigating Controls / Compensating Controls Creation of Mitigation Controls in GRC 10.0 Mitigating Control Lifecycle
	Finally, establish a new continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning on the system. Also make sure that all role changes must be analyzed and remediated before implementing. The outcome, and also final result, your system remains clean. Helpful documents: Approve/Reject Own Requests Risk Terminator - GRC 10

Now that we’ve covered the what and the why part we have to get our hands dirty and physically create them. If you have access to a Server, after following SAP documentation for 'From Post-Installation to First Risk Analysis' and 'Enhanced Access Risk Analysis', try executing the following tasks:

1. Create test users using SU01
2. Create test roles with Critical/Conflicting Actions using PFCG
3. Assign role/roles to test users including roles for Risk Owner , Mitigation Controller
4. Create Access Control Owners in NWBC
5. Check Configuration Parameters of Risk Analysis: SPRO -> IMG -> GRC -> Access Control -> Maintain Configuration Settings
6. Create/Check Business Process and Sub Process: SPRO -> IMG -> GRC -> Access Control -> Maintain Business Process and Sub processes
   • This will come in handy when creating Functions and Risks
7. Create Organizations: SPRO -> IMG -> GRC -> Shared Master Data -> create a Root Organization Hierarchy
   • You cannot create a Mitigation Control without this
8. Add Owners to the created Organization in NWBC: Setup -> Organizations
9. Run following Sync Jobs:  SPRO -> IMG -> GRC -> Access Control -> Synchronization Jobs
   • Authorization Sync
   • Repository Object Sync
10. Create the following in NWBC
    • Functions
    • Access Risks
    • Mitigation Control
11. Run a Risk Analysis against the Risks
12. Remediate using Simulation and see if it works
13. Mitigate Risks against User/Role/Profile
14. Create Alerts: SPRO -> IMG -> GRC -> Access Control -> ARA -> Generate Alerts
15. Setup Batch Risk Analysis on a periodic basis:  SPRO -> IMG -> GRC -> Access Control -> ARA -> Batch Risk Analysis

I sincerely hope this document will help you in your pursuit to get a grasp on what ARA is all about.

Please free to correct me if I made any mistakes or if you would like to add more on this matter. It would be nice to know what is done in regards to ARA, once we cross the bridge (the real world).

Regards,

Leo..

This document is a collection of the most useful SAP GRC Process Control documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

SAP BusinessObjects GRC 10.0 Integration Guide – Access and Process Control 10.0

General opinion and thought-leadership

Are you ready to implement GRC 10?

SAP BusinessObjects Process Control 3.0 Implementation Checklist

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

SAP BusinessObjects Process Control 3.0 Expert Guidelines, Tips, and Techniques to Successfully Implement SAP BusinessOb…

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects Process Control 3.0 Reports Description

SAP BusinessObjects Process Control 3.0 How-To Choose the Best Technique for Master Data Uploads

GRC General

General tips to help in troubleshooting scenarios

Debugging tips

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

Extended Workflows

Configuring Workflow E-mail Notification

CLM and MDUG

GRC Process Control 10.0: Content Lifecycle Management

Reports and Dashboards (RE)

How to Customize and Enhance reports in PC and RM

Automated Monitoring (AM)

How to set up a Configurable Business Rule

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

Legend

	SAP SCN Documents
	SAP SCN Blogs
	SAP Wiki

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro& Fernando

G’Day All,

Picking up from my previous topic aboutARA - For the new kid on the block, this document is just an overview of my understanding of what EAM is (from what I read here and SAP documentation) and how it works.

The objective of this document is to give people who are just starting out or even beginning to find their feet, a brief overview of EAM before they can get stuck into it and go all in(links provided). This is not intended for people who are well versed on this topic, so if that is you, please feel free to skip it as this might not interest you. However if you do want to stick around and point/correct any mistakes or offer advice/suggestions, please by all means do so. I am open to constructive criticism.

I understand there is a lot of content related to EAM in this site and some of the information covered herein might exist elsewhere in some shape or form however this is just meant to serve as a conduit for freshers, who might get a tad overwhelmed by all the information lying around. So I hope this document can give them a glimpse of what it is all about and then help them to venture out into the wild.

This pretty much is the gist of EAM. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Emergency Access Management (EAM).

http://scn.sap.com/docs/DOC-57438

A big ‘Thank You’ to the people who created and made these posts available for the benefit of people like myself. Your time/effort is very much appreciated guys.

Regards,

Leo..

This document is a collection of the most useful SAP GRC Risk Management documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

Overview of SAP BusinessObjects Risk Management 10.0

General opinion and thought-leadership

Are you ready to implement GRC 10?

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects RM 3.0 Quantitative Risk Analysis v1.0

Risk Management 3.0 Architecture Requirements

GRC General

General tips to help in troubleshooting scenarios

Debugging tips

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

Bow-Tie Risks

Integration with Bow-Tie Builder in Risk Management 10.0

Risk Aggregation

Risk Aggregation in RM 10.0

Integration

RM 10.0 Integration of Activity and Process Control local Sub processes

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

Legend

	SAP SCN Documents
	SAP SCN Blogs
	SAP Wiki

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro& Fernando

G’Day All,

Given the importance of Password Self Service and End User Logon, numerous posts out here in regards to its configuration and problems, coupled with my own interest in it; I began scouring through all the blogs related to these two topics and the result is as follows. I hope this will help you to some extent in understanding and configuring PSS and EUL.

As usual please free to correct me, if I made any mistakes or if you would like to add anything to this document.

Password Self Service

Password Self Service is a customizing activity, which enables an end user to reset their own passwords in the back end system. A user password is usually reset using TCode SU01. However considering this is restricted to end users and to help admins from being bogged down by constant password reset requests, a good alternative is to give the end user the option to reset their passwords themselves thereby freeing up the admins to do other tasks.   When an end user raises a request for a password reset, the application verifies the user based on the information they maintained for their password self-service settings or against the global PSS settings. Once the application verifies the user and the system, it resets the password and sends an e-mail to the user’s configured e-mail address. The password sent is a generic password, which the user needs to change upon their login.   * All end users need to have a valid email Id to receive reset password link Password Self Service Configuration Connector Settings Maintain Connector Settings: For each applicable system tick the PSS System Box SPRO -> IMG -> GRC -> AC -> Maintain Connector Settings Maintain Data Sources Configuration: Choose which system you check, for User Id to login SPRO -> IMG -> GRC -> AC -> Maintain Data Sources Configuration User Authentication Data Sources: Pick a System (ECC, LDAP, HR etc) User Search Data Sources: Pick a System (ECC, LDAP, HR etc) User Detail Data Sources: Pick a System (ECC, LDAP, HR etc) End User Verification: Choose YES/NO for Password requirement on logon screen Enabling End User Verification would require the end user to enter their password in order to login. However if a user needs to request a new password (obviously  they forgot the current one), it would be a catch 22 situation as pointed out by Colleen further down in the document (comments section). Disabling End User Verification would rectify this problem however that would raise a security issue, where any user can login using someone else’s user id and access their home screen and raise requests etc. This isn’t a huge problem as the request would go to the email address registered against their user id but still can be frowned upon and should be discouraged. A good compromise would be to Disable End User Verification and activate Challenger question (covered further down in the document). Even this has one potential downside to it, which is, if the end user hasn’t registered their answers against the questions then the previous scenario would come into play again!! So any suggestions from the seasoned community members here, who had to deal with this issue would be very much appreciated!   * You can configure multiple data sources. Preference is set by giving a sequence number Password Self Service Settings Run transaction SPRO. SPRO-> IMG -> Governance, Risk & Compliance -> Access Control -> User Provisioning -> Maintain Password Self Service On the left panel, under Dialog Structure, click PSS Global Configuration Values folder Click New Entries button. Under the PSS Global Configuration Values, enter the following: Authentication Source = Challenge Response When you select this option, the administrator configures the security questions  and the users register their answers. A user who creates a request to reset their password must answer the questions as they have registered them. The application only resets the passwords if the user successfully answers all of the questions PSS Disable Verification = None: Select this option if you want to enable PSS verification. Name Change Self Service: Select this option if you want to disable PSS verification in case the user only changes their name. Password Self Service: Select this option if you want to disable PSS verification in case the user changes their password. All: Select this option if you want to disable PSS verification in all situations. By choosing 'ALL', user would not need to register questions or receive a step in the password reset process to answer any questions. To answer a question/be challenged. Number of Questions = 2 (Minimum should be 1) Number of Attempts  = 3 (For Example) Click Save button. On the left panel, click the Challenge Response Questions folder. Click New Entries button. In the Challenge Response Questions, enter a Question in the field provided. Check the Active box. Click Save.   * If you chose HR System as the authentication source, then maintain the PSS HR System settings.

G'Day All,

In line with my other documents ARA - For the new kid on the block& EAM - For the new kid on the block, this is yet another document to help people who are new to this neck of the woods/Access Control, an overview of my understanding of what ARM is all about and how it works.

As usual feel free to skip it if you are well versed in this topic, however please do stick around and feel free to enlighten me with your expertise if I made any mistakes or if you would like to correct/add more on/to this topic. 

This pretty much is the gist of ARM and should be enough to get you started. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Access Request Management (ARM).

http://scn.sap.com/docs/DOC-57438

Regards,

Leo..

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBA's for GRC Access Controls in the month of August 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Access Controls.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Purpose

The purpose of this document is to provide a list of the top ten most viewed SAP KBA's for GRC Process Controls in the month of August 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Controls.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Related Content

Top 10 most viewed SAP KBA's for GRC Process Control in July 2014

Top 10 most viewed SAP KBA's for GRC Process Control in June 2014

Top 10 most viewed SAP KBA's for GRC Process Control in May 2014

Top 10 most viewed SAP KBA's for GRC Process Control in April 2014

This document is a collection of the most useful SAP GRC Access Control documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Processes, Lifecycles and Responsibilities

General opinion and thought-leadership

Are you ready to implement GRC 10?

A lot of help from my friends

If I had it to do all over: looking back on GRC 10 projects

Lessons learned from SAP GRC projects

Remediating Access Control SoD Risks

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

IT Control Testing - SOX Compliance

A #GRC tool is just part of the solution

GRC General

NWBC screen layout options for GRC

Customizing NWBC for New Menus with our own Transactions, Reports and Accessing SAP Backend Systems from NWBC

Configure LaunchPad for Menus

Customizing Access request and approval screens in GRC Access Control

Issues, Bugs in GRC SP13 - Related Fixes

General tips to help in troubleshooting scenarios

Access Control Debugging tips

HR Triggers

Understanding HR Triggers in Access Control 10.0 - Governance, Risk and Compliance - SCN Wiki

GRC 10.0 - HR Trigger configuration - Governance, Risk and Compliance - SCN Wiki

Example of decision table for GRC 10 HR Trigger rule, using BRF+ tool

GRC Access Control - Compliant User Provisioning: HR Triggers

Debugging HR Trigger - GRAC_HR_TRIGGER_EVENT_RECIEVER

Debugging HR Trigger - Simulation

Debugging HR Trigger - PA40 changes to infotypes

MSMP Workflows

AC 10.0 - Customizing Workflows for Access Management

MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

LDAP

Configuring LDAP Connector in Compliant User Provisioning of GRC Access Control

LDAP Group parameter mapping.. what does it mean?

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

Access Risk Analysis (ARA)

Rule set - Rules & Rule Types

Business Risks / Rule Set

How to set up a Configurable Business Rule

Online vs. Offline Risk Analysis

Creation of Mitigation Controls in GRC 10.0

Organizational Rules in GRC Access Control

Mass change of Mitigation Assignments

SAP GRC AC 10.0 Alerting

The Action Usage Sync job in technical details - GRC Access Control 10.0

The Repository - GRC Access Control 10.0 

Access Request Management (ARM)

AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls

Approve/Reject Own Requests

How to Change Subject Line in SAP GRC Email notification

Recommendations for using Business roles provisioning in access request

Configure Manager Look-Up in ARM for GRC 10

Role Search Screen Enhancement – GRC 10

Terminate Account - Request Process - GRC 10

Creating Access Request: Template Based Requests and Configuring End User Personalization forms for use with Access Requ…

GRC Request with both System and Role Line Items

Access Control 10 (ARM) – Risk Analysis Report Type is editable in Access Request.

Access Control: - Create Access Request Using Web Service in GRC10

User Access Review(UAR) Workflow Configuration and Description - Governance, Risk and Compliance - SCN Wiki

Business Role Management (BRM)

Maintain Default Roles in BRM GRC AC 10.1

Role Import - GRC 10

Import Role from ECC to GRC system

Business Roles concept and usability in GRC AC10 

Emergency Access Management (EAM)

EAM - Provisioning Strategies

ID-Based Firefighting vs. Role-Based Firefighting

AC 10.0 - Centralized Emergency Access

Configure Emergency Access (EAM) in GRC 10

De-centralized EAM GRC 10.0

EAM - Approve through Wrokflow

Emergency Access Management Reporting

See also

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

Legend

	SAP SCN Documents
	SAP SCN Blogs
	SAP Wiki

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro

This document is a collection of the most useful SAP Fraud Management documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

General opinion and thought-leadership

Are you ready to implement GRC 10?

GRC General

General tips to help in troubleshooting scenarios

Debugging tips

Fraud Management

SAP Fraud Management - Governance, Risk and Compliance - SCN Wiki

SAP Fraud Management@HANA

Extended Anti-Corruption Content with SAP Fraud Management Release 1.1 SP01

SAP Fraud Management Released with New SAP Audit Management Solution

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

Video tutorials

Video Tutorials for SAP Fraud Management

High Risk Rule

How to Create a High-Risk Country Rule

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

Legend

	SAP SCN Documents
	SAP SCN Blogs
	SAP Wiki

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro& Fernando

G’Day All,

Considering the fact that so many people out here, have so selflessly shared their expertise through blogs, answers etc. So its only fair that I do my bit to balance the scales. Now if what I contribute is worth it or not, that's a different story and I shall leave it to the moderators to judge for themselves.

The topic I would like to present to you is ARA. Just a heads up that whatever is presented here is just an overview of my understanding of what ARA is (from what I read here and SAP documentation) and how it works. I’ll leave it to the experts here to make corrections/suggestions if the need be for the benefit of everyone reading this document and myself included.

A lot of the key terminology has been explained rather brilliantly by Alessandro in the following two documents, so there is no point in me trying to reinvent the wheel.

http://scn.sap.com/docs/DOC-54434

http://scn.sap.com/docs/DOC-54530

So here we go.

This entire process is termed as 'SOD Management Process'.

Segregation of Duties (SoD) is an internal control within a Company implemented to prevent or decrease the risk of errors or regulatory irregularities and ensure corrective action is taken. Ideally, no one individual must have the authority of:

Creation .Modification .Reviewing .Deletion

SoD ensures no single user has access to separate phases of these business transactions. This is done by Dividing, Distributing and Allocating key tasks amongst various individuals thereby eliminating or at least reducing the possibility of errors and fraud.

All of this is carried out in three separate phases:

Phase 1

Risk Recognition

Rule Building & Validation

Phase 2

Risk Analysis

Remediation

Mitigation

Phase 3

Continuous Compliance

*Credit for the following SOD Management Process flow goes to: Alessandro& Colleen

Steps	Description
	Gather a list of applicable SOD conflicts that allow fraud or generate significant errors. The outcome of this step is that your business has determined what is an unacceptable risk that they want to report on and manage via remediation or mitigation.   Helpful documents: Risk Lifecycle
	Build the rule set based on the recognized risks from step 1. The outcome of this step is the technical rule set to analyze the user and/or role assignments.   Helpful documents: Business Risks / Rule Set Rule set - Rules & Rule Types
	Analyze the SoD output. This can be performed with the help of SAP GRC Access Control. In case of manual analysis, for each user, analyze if he/she has the access to perform any of the conflicting functions defined in step 1. The outcome is basically to provide the business insight to alternatives for correcting or eliminating discovered risks.   Helpful documents: Online vs. Offline Risk Analysis
	In this step, evaluate if the conflicting tasks can be performed by an alternate person. If so, role changes and/or user reassignments can be performed to segregate duties properly. The outcome must be a very low number of remaining risks that need mitigation.   Helpful documents: Remediating Access Control SoD Risks
	If it would not be possible to remediate the existing conflicts, consider formulating an appropriate control to mitigate the risk. This would typically entail working with the business to setup additional monitoring procedures that ensure to compensate the risk. The outcome must be no remaining risks.   Helpful documents: Internal Controls - a step towards strong controls Defining Mitigating Controls / Compensating Controls Creation of Mitigation Controls in GRC 10.0 Mitigating Control Lifecycle
	Finally, establish a new continuous process wherein every access request is reviewed against the SoD conflict matrix prior to provisioning on the system. Also make sure that all role changes must be analyzed and remediated before implementing. The outcome, and also final result, your system remains clean. Helpful documents: Approve/Reject Own Requests Risk Terminator on SAP Wiki

Now that we’ve covered the what and the why part we have to get our hands dirty and physically create them. If you have access to a Server, after following SAP documentation for 'From Post-Installation to First Risk Analysis' and 'Enhanced Access Risk Analysis', try executing the following tasks:

1. Create test users using SU01
2. Create test roles with Critical/Conflicting Actions using PFCG
3. Assign role/roles to test users including roles for Risk Owner , Mitigation Controller
4. Create Access Control Owners in NWBC
5. Check Configuration Parameters of Risk Analysis: SPRO -> IMG -> GRC -> Access Control -> Maintain Configuration Settings
6. Create/Check Business Process and Sub Process: SPRO -> IMG -> GRC -> Access Control -> Maintain Business Process and Sub processes
   • This will come in handy when creating Functions and Risks
7. Create Organizations: SPRO -> IMG -> GRC -> Shared Master Data -> create a Root Organization Hierarchy
   • You cannot create a Mitigation Control without this
8. Add Owners to the created Organization in NWBC: Setup -> Organizations
9. Run following Sync Jobs:  SPRO -> IMG -> GRC -> Access Control -> Synchronization Jobs
   • Authorization Sync
   • Repository Object Sync
10. Create the following in NWBC
    • Functions
    • Access Risks
    • Mitigation Control
11. Run a Risk Analysis against the Risks
12. Remediate using Simulation and see if it works
13. Mitigate Risks against User/Role/Profile
14. Create Alerts: SPRO -> IMG -> GRC -> Access Control -> ARA -> Generate Alerts
15. Setup Batch Risk Analysis on a periodic basis:  SPRO -> IMG -> GRC -> Access Control -> ARA -> Batch Risk Analysis

I sincerely hope this document will help you in your pursuit to get a grasp on what ARA is all about.

Please free to correct me if I made any mistakes or if you would like to add more on this matter. It would be nice to know what is done in regards to ARA, once we cross the bridge (the real world).

Regards,

Leo..

Every Business has its own requirement. With the feature of custom fields we can full fill it to some extent.

Adding Non-HR User-Defined Fields in Access Control 2010

This paper covers adding customer-specific fields for Request objects (related to compliant user provisioning).

Supported customer-specific fields

Staring release 2010 there are more flexibility in defining the customer-specific fields. You can define them as Single value for access controls.

Each category of customer specific fields is stored differently within the databases structures. Single value fields uses customer includes in mater tables of the entities (see chapter “Use Data Elements to Enhance the Data Storage for single value fields” for details).

Example

This example describes how to add a customer-defined field to a request object. These procedures apply to other objects also. The example shows how to add one field to the request object.

Overview of Tasks

1. Creating data elements and storage for new fields in the ABAP dictionary

2. Displaying/editing new fields in the Web UI. Custom fields are displayed on the UI automatically. There is an optional BAdI implementation to change the look of the fields or to default a value etc.

To perform these tasks:

 You must have the S_DEVELOP authorization profile or the equivalent

 You must test all changes in the development system first before transporting them to the test and production systems.

Note: The changes do not cause conflicts with upgrades since they are not considered as modifications of the delivered SAP standard.

Modifying the ABAP Dictionary

As an example, these instructions create the data element for a calendar date.

Creating an extra data element (and not reusing the existing one) is important because the User Interface and reporting take the captions from the definition of the data element.

1. Input transaction SE11 (ABAP Dictionary).

2. Input the name of the Domain. For the example, use ZREQSTAT. Create a logical prefix for your naming convention, starting with Z or Y to indicate that it is a customer-specific namespace.

3. Choose Create and select the data element ZREQSTAT. After you activate the object, you must put the data element into your customer-specific package.

4. To create a new data element, you have to maintain the description and the domain:

Note: Write the description according to your project standards. For the example, the domain is the standard one for the calendar date.

5. Select the Field Labels tab and maintain the texts there based on what you want to see on your Process Control screens and reports.

Note: If multiple languages are needed, input transaction SE63 and enter the text in the languages needed.

6. Save, check and activate your new data element.

Creating a field with a fixed list of possible values

1. Input transaction SE11

2. Input the name of the Data type. For the example, use ZREQSTAT. Create a logical prefix for your naming convention, starting with Z or Y to indicate it is a customer-specific name-space.

3. Choose Create.

4. Enter the Short Description and the Data Type (CHAR).

5. Enter the length of the field. For the example, use 1 in order to store the fixed values associated with a single character:

6. Select the Value Range tab and enter the set of the fixed values and their association with descriptive texts.

Note: If multiple languages needed, input transaction SE63 and enter the text in the languages needed.

7. Save, check and activate the new domain.

Note: Now the domain can be used to create the data element. The procedure is the same as with the data element above: transaction SE11, the data type ZREQSTAT, choose Create, provide the description, as the domain use your brand new domain ZREQSTAT and provide the field labels. Save, check, activate.

Use Data Elements to Enhance the Data Storage for single value fields

Here is the list of all the tables/objects that can be enhanced using similar steps:

Object Name               Database Table             Customer Include

Request Attributes      GRACREQ                    CI_GRAC_REQ_ATTR

1. Using transaction SE11, and specify the table name. For the example, use GRACREQ.

2. Choose Display.

3. Search through the list of components of the table GRACREQ. At the bottom, locate the customer include. This is where you can add your own fields.

This example focuses on providing one status field explicitly and uses the structure CI_GRAC_REQ_ATTR. This structure will be used within the table, but it does not yet exist. During the next steps, you will create the structure.

1. Select the structure CI_GRAC_REQ_ATTR. A dialog box tells you that the structure does not exist and asks whether you want to create it.

2. Confirm that you want to create it.

3. Provide the Description of the structure and include one field: ZZ_REQSTAT type Z_REQSTAT

Note:

a. The field names are prefixed with ZZ (or YY) to ensure that there is no overlap with the delivered SAP fieldnames.

b. Keep the names unique. All customer fields are used in the global reporting structure. If the same field is used twice, it causes problems.

c. Verify the field name is no longer than 16 characters. Otherwise you cannot activate your customer include structure.

Note: For the structure CI_GRAC_REQ_ATTR you must enter information about the Enhancement Category. Because this Customer Include Structure is already an Enhancement Structure, it cannot be further enhanced. Follow the menu path Extras -> Enhancement Category. In the window that appears, indicate that the structure Cannot Be Enhanced and choose Copy.

4. Save, check and activate the structure. Several dependent structures and database (DB) tables are reactivated too, as they include the structure

CI_GRAC_REQ_ATTR. You require powerful authorization to be able to activate the DB tables (for example, the authorization object is S_DEVELOP, with fields OBJTYPE=TABL and ACTVT=07). After the activation, you receive a warning which informs you about the dependent tables, which are implicitly activated with CI_GRAC_REQ_ATTR.

All the dictionary work is done. The case objects for the issues are enhanced with this additional field.

Regards,

Nidhi mahajan

Purpose of User Defaults:

When a new user is being created in the target system, all users of that system might require few common user defaults like Logon Language, Time Zone, Decimal Notation, Date Format, Parameters etc. Hence when a user is getting created through GRC, based on the request type these user defaults can be assigned to the users.

By including user defaults as part of request type (mostly New Account), user gets created with required user defaults in the target system.

Important SAP notes regarding User Defaults to refer before configuring User Defaults:

1615552 - GRC 10.0 How to set User Default

1665585 - User Defaults BRF+ rule not working correctly

2020712 - UAM: User group not provisioned after request provisioning

Steps to Implement User Defaults:

Step 1: Maintain “User Defaults “action as part of your Request Type. My Request Type 36 is for “New Account” and I have assigned “User Defaults” as shown below.

SPRO =>Governance, Risk and Compliance =>Access Control =>User Provisioning =>Define Request Type

Step 2: Go to SPRO -> IMG -> GRC -> Access Control -> User Provisioning -> Maintain User Defaults

Define User defaults for different connectors connected to your GRC system. One example as shown below:

You can assign default User Group and default Parameters based on the connector by using options “Set the User Group” and “Set Parameter ID” in the above screen as per your requirement.

Once you define the User Defaults as mentioned above and save it, a unique “Default-Id” gets created as shown below. This is the User Default Id which will be used in BRF+ decision table while configuring User Defaults.

Step 3: Existing BRF+ User Defaults application “GRAC_BRFP_USER_DEFAULTS” provided by SAP will be used during configuration of user defaults.

Copy the Function Id of USER_DEFAULT_FUNCTION from BRF+ application.

Now map the BRF+ Application for user defaults under the IMG configuration shown below:

Go to IMG->Governance, Risk and Compliance->Access Control->Maintain AC Applications and BRFPlus Function Mapping

Step 4: Add Decision Table and Loop expression to BRF+ User Defaults function as shown below:

Decision Table: In the decision table maintain entries as shown below

Loop: For using "System" as one of the fields in setting the conditions for User Defaults, SAP suggested for implementing a LOOP in BRF+ Rule. This might be needed since "System" field is not available under Request Header attributes, rather it is available as Role Attributes which are called as line-item fields while calling the BRF Rule. So, in such cases LOOP is a suggested solution, rather than using the Decision Table directly. Though within the LOOP, we can still call the Decision Table or implement IF/ELSE conditions.

Ruleset: When a Function is in event mode, it looks for additional logic execution depending on the Rule-set defined.

Once all above things are done, activate the Decision table, Loop, Ruleset, Function and Application.

Step 5:  Now Create an Access request to test the User defaults and once the User is created please cross check the User Defaults in SU01 to check if everything is fine. If all the above steps are followed properly, User defaults will get updated properly as below in SU01.

Reference Links: http://wiki.scn.sap.com/wiki/display/GRC/Setting+up+User+Defaults