Wednesday 30 October 2013

GooD Link For GRC 5.3,10.0,10.1 Information

http://wiki.scn.sap.com/wiki/display/GRC/Governance%2C+Risk+and+Compliance+Home

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

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

Sourse: http://scn.sap.com/docs/DOC-46091

In Access Request, sometimes you would want to route your request based on the risk violations present in the request. There are some standard function module based detour/initiator rules which are available in MSMP like 'GRAC_INITIATOR_SOD_VIOLATIONS' and 'GRAC_MSMP_DETOUR_SODVIOL' where you can route your request based on risk violations. But these standard rules are inflexible, so if you want to add another condition for routing along with risk violation then you will have to change the abap logic within these function modules.

So using these standard rules you can route request based on risk violation only. If you want to create an initiator rule based on risk violation and 'Sensitivity' of role or if you want to create a routing rule based on the 'Risk Level' of violations then it is not possible using standard rules unless you change ABAP logic.

In this document we will see how we can utilize power of BRF+ by creating a very flexible initiator/routing rule where we can check combination of multiple conditions and not just Risk Violations. We will be taking example of following business scenario :

Business Scenario :

If an access request contains risk violations with Risk Level as 'High', then the request should be routed to a special path, and if no violations with Risk Level 'High' are found, then continue with normal path

We will use BRF+ procedure call to get risk violations in the request. In BRF+ Procedure call, we will use one of the standard function module to get risk violation details of a request.

Follow steps below to create a BRF+ flat rule to achieve above scenario

1.) Generate BRF+ Shell for Access Request Initiator from transaction 'GRFNMW_DEV_RULES'

Fill generation criteria (Process ID, Rule type, etc.)
Specify Generation options and select any field from Header or Item to ensure decision table is generated automatically
Generate rule shell (Execute button)

2.) Activate Empty BRF+ Rule using transaction BRF+

To locate the generated function, use menu, 'Workbench -> Open Object' and specify object ID from previous step
Activate the function
Change the mode to “Event Mode”

3.) Change Result Data Object of BRF Function

Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
In “Signature” tab of BRF Function, change the result data object to GRFN_MW_S_ROUTING

4.) Function Module to Get Risk Violation Details

We will be calling function module “GRAC_IDM_RISK_WITH_NO_SERVICES” in BRF+ rule to get violations details
It returns a table with violations; so first, we will create a table in BRF rule which will hold the result of the function call

5.) Create Data Object

From context menu of BRF+ application, create a Data Object of type “Table”
This data object will hold the risk analysis result

Select DDIC Binding and provide name of DIDC Table Type of “GRAC_T_WS_RA_OP_RISK_ANLYS_ID”
Activate the Data Object

6.) Create Procedure Call to Get Risk Analysis Result

Create a procedure call from context menu of BRF application

Within procedure call, select Call Type of “Function Module” and provide Function module name as “GRAC_IDM_RISK_WITH_NO_SERVICES.” Press “Enter” key after providing function module name.
Add parameters to the procedure call

Select the Data Object created in step 5 as “Result Data Object” for this procedure call

Map Parameters to Context Fields

Click on Mapped parameters to expand the details
Assign value to these parameters using BRF+ context parameters
Activate procedure call

7.) Create Expression — Table Operation : Check Risk Analysis Result Table for Risks

Create an expression of type “Table Operation”
This expression will read the result table of procedure call to check if any violations exist

This expression will read the result table of procedure call “RISK_ANALYSIS_RESULT” to check if any violations exist
Additionally, here we are checking for any risk with “High” risk level
Activate “Table Operation” expression

8.) Add Condition Column to Decision Table

Go to Decision Table that was generated automatically
From decision table settings, add a column from expression and use expression “READ_RISK_VIOLATION,” which is a table operation

9.) Add Business Logic to Decision Table

Add conditions to the decision table
Based on the result of “Table Operation,” which checks whether any “High” risk violations exist in request or not, the path of request is decided

10.) Create Ruleset

Go to BRF+ function and create a new ruleset

Add variable “RISK_ANALYSIS_RESULT,” which was created in previous steps, to the ruleset

11.) Add Rule to Ruleset

Create new rule within ruleset
Within this new rule, call the procedure that was created in previous steps

12.) Add Second Rule to Ruleset

Within same ruleset, create second rule that will call the “Table Operation” expression “READ_RISK_VIOLATION”
This table operation will read the violations, which are returned by procedure call

13.) Add Third Rule to Ruleset

Within same ruleset, create third rule that will call the “Decision Table” expression
Decision table operation will internally call table operation to check if any violation was returned by procedure call and, based on the result, it can decide the path of request

14.) Check sequence of rules within ruleset

Check the sequence of rules within ruleset
First rule in the sequence should be procedure call, second should be table operation, and last should be decision table
Activate all objects

Now you can configure this rule in msmp configuration and use it as routing or initiator rule

BRM Approver Condition Group

Implement Condition Groups in Role Management

Skip to end of metadata

Go to start of metadata

Purpose

This document explains the steps on how to create a Business Rule Framework (BRF+) Rule for using in Condition Groups in Role Management for routing the Approver during the Role Creation process.

Overview

While creating the Roles in GRC 10.0 via Role Management, we have the capability to define the rules for the application to determine the Role Content Approver during the Approval phase.

Similar to the version 5.3, in GRC 10.0, we have the provision to define the Condition Groups in GRC so that the application can determine the Role Approvers based on a certain set of conditions to which the Condition Group would be mapped. You can build the conditioning on the basis of various Role Attributes, available as a Context Structure while defining the BRF+ Rule.

Please note, you have to create a BRF+ rule from within the SPRO and within the GRC node in order for the BRF rule to pull the Context Attributes/Parameters related to Role Management.

NOTE: You also have the capability to define the Methodology based on the Condition Groups conditions from the BRFplus rule. This document only covers the Condition based Approver.

Steps to build the BRF Rule

You have to generate the BRF Rule via Transaction SPRO in GRC system. Follow the below steps in your GRC system.

Run the transaction SPRO, Goto Governance, Risk and Compliance =>Access Control =>Role Management. Further you find the option for generating the BRF Rule related to Role Management areas. Follow the screen capture below:

Maintain the field values as shown in next screen. You can use any relevant names in these fields.

Click Execute or Press F8. This now generates a successful message for BRFplus Rule with name and ID.

Copy this Rule ID for use in BRF+ screen which opens in the browser.

Now run the transaction BRF+ in the GRC system to get to the BRF+ screen in browser.

Navigate to the Menu, Workbench =>Open Object and enter the Rule ID (alphanumeric code) copied as above and press “Show”.

Next screen opens the BRF+ Rule you have created.

Now, create a Decision Table by righ-clicking the Application Name which is the top node of your Object and choose Create =>Expression =>Decsion Table.

Maintain any desired name/text for your Decision Table based on your business naming conventions. Click "Create And Navigate to Object" button.

Now you can add the required Role Attributes based on which the conditions can be defined for setting the Approval. In this case, we have chosen "Role Type" as example.

Assign the above created Decision Table to the Function as Top Expression.

Save and Activate the Application and objects.

Implement the BRF Rule with Condition Group.

You now have to assign the Approver Condition Group to the above created BRFplus Application Name and BRFplus Function Name used in BRFplus screen in the browser.

Do the assignment as per the below screen.

NOTE: In this context, the Condition Groups are just being implemented for Approval.
Go to NWBC and click on Role Owner option under "Role Assignment" or "Access Owners".

Maintain the condition group with same name as in BRF+ and assign approver to it.

Now create the role and the corresponding Role Owner will be added based on Condition Group satisfied by the Decision Table context of the BRFplus rule.

Tuesday 29 October 2013

SAP ACCESS CONTROL 10.1 Product Information Matrix

Good Link For BRM in GRC AC 10

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80063a8e-1da6-2e10-aaa5-fda1f0936c37?QuickLink=index&overridelayout=true&51947629452072

Configuration Of Emergency Access Management(Fire Fighter) In GRC AC 10

Configure Emergency Access (EAM) in GRC 10

Sourse : http://scn.sap.com/docs/DOC-33099

Configuring EAM in GRC 10 isn’t a difficult task, but there are some details you have to take into account. The document “AC 10.0 Pre-Implementation From Post-Installation to First Emergency Access” is useful, but it doesn’t consider all the details. Here I’ll try to give you a complete explanation about how to configure EAM successfully.

Configure Parameters:

In GRC Box, execute transaction SPRO and navigate to here:

The following parameters should be set according to the table:

*Parameter*	*Recommended value (for initial configuration)*
4000‐Application type	1
4001‐Default Firefighter Validity Period (Days)	30
4002‐Send Email Immediately	YES
4003‐Retrieve Change Log	YES
4004‐Retrieve System log	YES
4005‐Retrieve Audit log	YES
4006‐Retrieve OS Command log	YES
4007‐Send Log Report Execution Notification Immediately	YES
4008‐Send FirefightId Login Notification	YES
4009‐Log Report Execution Notification	YES
4010‐Firefighter ID role name	Chose a role name, for example Z_SAP_GRC_SPM_FFID

For a complete description of the above parameters, please refer to the guide:

https://service.sap.com/instguides - > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Maintaining Configuration Settings Guide - SAP AC 10.0

Current direct link:

http://service.sap.com/~sapdownload/011000358700000997872011E/AC10_ConfigSettings_SP10.pdf

You might want to change some of them; the recommended values only serve as a guide for the initial configuration.

Changes in the parameters table will be included in a transport request, you should release the transport to your QA/PROD systems when you finish the EAM tests and adapt the parameters according to your requirements.

Parameter 4010: What’s for?

If you’ve been working with GRC 5.3, this parameter should sound weird to you.

The purpose is to identify to the application that the user who is logging on to the target system is a Firefighter ID. The target system makes a call to the GRC Box and reads this configuration to check if the user has this role assigned to them.

That means that you have to create the role that you’ve set in parameter 4010 in all the target systems with the exact name provided there. Usually, you copy it from the standard SAP_GRC_SPM_FFID (it contains RFC authorizations).

Only the users who have that role assigned in the target system will be available for selection in the GRC Box as Firefighters IDs.

Kindly check note: 1668255 - Firefighter ID role name for Param ID 4010

For more information regarding default roles provided by SAP, please refer to Security Guide available here:

https://service.sap.com/instguides - > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Security Guide - SAP Access Control 10.0

Current direct link:

http:/service.sap.com/~sapdownload/011000358700001377352010E/ACPCRM10_SG_SP10_en.pdf

Adding connector to the SUPMG Scenario:

Please check: Note 1562760 - AC10.0 - Intergration Scenarios to Connector link

At this point you have already created the connectors.

Now you have to link the corresponding connectors to the SUPMG scenario:

Click here:

And:

Required roles in the GRC Box:

SAP provides standard roles that must be copied to the customer namespace. For this sample configuration you should need at least to create a copy for the following roles and generate the corresponding profiles:

SAP_GRAC_SUPER_USER_MGMT_OWNER

Emergency Access management owner

SAP_GRAC_SUPER_USER_MGMT_CNTLR

Emergency Access management controller

SAP_GRAC_SUPER_USER_MGMT_USER

Emergency Access management firefighter

SAP_GRAC_SUPER_USER_MGMT_ADMIN

Emergency Access management administrator

SAP_GRAC_BASE

Gives basic authorizations required for all AC users. You must assign this role to all AC users.

SAP_GRAC_NWBC

Gives the authorizations to launch NWBC. You must assign this role to all AC users.

You can just name them as Z_<full standard role name> or use a naming convention according to your company requirements.

CAUTION: Please, follow he instructions provided in tha attachment of note:

Note 1663949 - EAM Authorization Fixes for Central Owners and Reason Codes

There are some changes you have to made to the standard roles and also there's a complete explanation of the authorization objects.

For more information, kindly refer to the Security Guide (link provided above).

Security considerations for EAM Roles:

Kindly read a specific authorization guide for EAM that is attached to the note:
Note 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes

and take into account the authorization concept for the roles:

1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User

"As per the functionality in AC10, we have concept of role based authorization. If a user is having SAP_GRAC_SUPER_USER_MGMT_OWNER role at the backend, then he should be able to assign any FFID to any Firefighter user.

The user Assigned with the Role of EAM Admin “SAP_GRAC_SUPER_USER_MGMT_ADMIN”
and EAM Owner “SAP_GRAC_SUPER_USER_MGMT_OWNER ” can do all available owner action for all connector.
The Auth. Object used for firefighter Maintenance is GRAC_FFOWN & GRAC_OWNER"

Required users in the GRC Box:

In order to show a sample for testing, It’s necessary to create (or use existing ones) three users:

FF_OWNER: This user will serve as owner for the firefighter ID. It should be assigned to the role Z_SAP_GRAC_SUPER_USER_MGMT_OWNER

FF_CONTROL: This is the firefighter controller. You assign Z_SAP_GRAC_SUPER_USER_MGMT_CNTLR.

CAUTION: This user MUST have a valid e-mail address maintained in SU01 if you want the controller to receive notifications via e-mail.

FIREFIGHTER: This is the firefighter user, who will be able to access in the target system with the Firefighter ID. You assign Z_SAP_GRAC_SUPER_USER_MGMT_USER in addition to the base roles. If you don't assign the base roles you won't see the user (FIREFIGHTER in this case) available for selection in the Firefighters IDs.

<your user>: The user who is going to perform the configurations, must have at least the role Z_SAP_GRAC_SUPER_USER_MGMT_ADMIN assigned.

In addition to all the mentioned roles above, all users must have the roles Z_SAP_GRAC_NWBC and Z_SAP_GRAC_BASE assigned.

For a theoretical explanation of the users and its responsibilities, refer tohttps://help.sap.com/saphelp_grcac10/helpdata/en/16/404938695540b398a5e76fe8cfb067/frameset.htm

Required roles in the target system:

In the target system you have to make a copy of the role SAP_GRAC_SPM_FFID and generate the profile.

CAUTION: The name of this role MUST be the same configured in the parameter 4010 in the GRC Box. In this example: Z_SAP_GRC_SPM_FFID.

Required users in the target system:

You have to create a user (FIREFIGHTER_ID) in the target system with the corresponding roles required roles/profiles according to your requirements. In addition you must assign to the FIREFIGHTER_ID the role Z_SAP_GRC_SPM_FFID.

This user should be of type: “Service” as per note 1702439

The following note describes an issue you'll face with this kind of users: Note 1586989 - Object Services icon not available in Firefighter ID session

I'll update this document when a specific note for GRC 10 is released regarding this issue.

Creating central Owners and controllers:

Access to the NWBC: http://<server>:<port>/nwbc/ or execute tx. NWBC in the GRC Box.

Go to the “Setup” tab and:

Create entries for the Firefighter controller and owner:

Creating reason codes:

You have to create at least one reason code to be able to use the firefighter ID later.

Associate the entry to the corresponding target system.

Synchronization Jobs:

In accordance with note: 1585079

You have to execute the synchronization Jobs in order to make the FF IDs available in GRC Box for selection:

Please make sure that you have performed following configuration steps:

1. Integration Scenarios are configured as explained in note 1562760
2. Please make sure the Firefighter role is assigned to Firefighter IDs in the corresponding client system and that the same role has been given as parameter value for configuration parameter 4010. Configuration parameters can be configured in the transaction code SPRO => Governance, Risk & Compliance => Access Control => Maintain Configuration Settings
3. Run User/Role/Profile/Auth synchronization jobs. The Link to run these jobs can be found Under transaction code SPRO => Governance, Risk & Compliance => Access Control => Synchronization Jobs.

Once you have executed the auth & repository sync job with the corresponding target connector, the FF ID will be available for selection in the GRC Box.

!!NEW: Decentralized firefighting (as in GRC 5.3) is available as of SP10

As of SP10, Emergency Access decentralized firefighting features are available.Users can install and use the EAM Launchpad to perform ID-based firefighting directly on plug-in systems. This means that Firefighter session could be started from the plugin system itself without the need to access the GRC Box. This approach was used in GRC 5.3. With GRC 10 SP10 you can chose between centralized or decentralized firefighting.

The most important advantage of decentralized firefighting is that you can continue using firefighter even when the GRC Box is down. In my opinion, it’s also more “user-friendly” since the firefighter doesn’t have to log on to GRC Box in order to start the firefighting session, he/she only needs to execute a transaction in the plugin system. For some companies, the centralized approach is better since the user access to a system (GRC Box) and can start firefighter sessions in multiple systems.

Bottom line, the most important thing is that with SP10 you have to option to choose and below you’ll find information that’ll help you to configure decentralized Firefighting.

The idea of a decentralized firefighting was submitted by Daniela Bork on SAP Idea Place: Access Firefighter application locally in AC10

So, if you have a good Idea, please share it with SAP customers and employees in the Idea Place and maybe it becomes a new functionality!

WARNING: THE FOLLOWING PROCEDURE ISN’T PROPERLY DOCUMENTED. I’LL ADD INFORMATION OR CHANGE THE PROCEDURE AS SOON AS NEW GUIDES ARE AVAILABLE.

Main documentation can be found in the guide attached to the note: Note 1690964 - Emergency Access Management Overview Documentation

In the GRC Box a new parameter is available and must be set accordingly:

Under transaction SPRO, navigate to here:

And create a new entry for parameter 4015 which has to be set to the value “YES”

Additionally a new synchronization job is available and must be executed in order to synchronize the EAM data from GRC Box to the plug-in system. Remember that configurations (firefighter assignments, controllers, owners, reason codes, etc.) are still maintained in a centralized way, i.e in the GRC Box.

In order to sync this data with the plug-in, a new job is available and can be found here:

In the connector field you have to set the corresponding plug-in connector. In order to keep you plugin system updated with the changes you made in the GRC Box, this report should be scheduled periodically, I think hourly would be fine. In addition, if you have multiple plug-in systems, you should follow the same approach as with the log synch: create individual jobs for each connector instead of a unique job with connector value “*”.

Configuration in the plug-in system

In the plug-in system you’ll find new activities under SPRO:

These activities are described in here: 1804207 - GRC EAM 10.0: Configuration parameters introduced in SP10 for EAM

If you haven’t set the parameter 1000 in the plug-in system, you’ll have to do it in order to use decentralized firefighting, otherwise you’ll get an error message as described here:1800772 - Error 'No Destination specified' when using transaction /GRCPI/GRIA_EAM

Then, check the parameter as described below:

If the parameter 1000 isn’t present you have to create it and set the value to an RFC destination pointing to the system itself:

Since this configuration is transported I recommend to create a new RFC destination in DEV, QAS and PRD system with the same name, let’s say “GRC_CONNECTOR”. This will allow you to transport the configuration throughout your entire landscape.

The RFC connection does not require a user. It just has to point to the correct system/instance and a specific client.

Required users

Controllers have to be created in the GRC Box as well as with centralized firefighting. In addition these users must exist in the plugin system and have a valid e-mail address because login notifications are sent from plug-in system

With the decentralized scheme it’s not necessary to create the firefighter users in the GRC Box, because they’ll start firefighter transaction from the plug-in system.

E-mail considerations

Log-in notifications are sent from the plug-in system:

But, as with the decentralized approach, Log notifications are sent from GRC Box

These requires a proper mail configuration (tx. SCOT) in both systems: plug-in and GRC Box.

Plug-in roles

You’ll have to create a new role as a copy of SAP_GRAC_SUPER_USER_MGMT_USER.

You should add the following authorization to it:

For some NW releases ACTVT=02 will be also required. Kindly Check 1753459 - EAM: S_USER_GRP with ACTVT=02 required

This role is assigned to the firefighter users. Bear in mind that these users should not have access to user maintenance transactions, for example SU01. If the firefighter IDs are properly assigned to a group and you can restrict the CLASS field this is not a big issue, since despite they could change the password, they won’t be able to access because the user exit is implemented in order to prevent it.

The authorization added to the role SAP_GRAC_SUPER_USER_MGMT_USER isn’t properly documented by SAP yet. It might be another way to configure it...but this was the same approach used in GRC 5.3.

In addition to this role you also have to create roles for administrator and owner. Remember that extending the validity period is a new activity available in the plug-in system and owners and administrators should have access to it.

Known Problems ( specific to decentralized EAM)

Note 1849289 - For Decentral EAM No Reasoncode and Activity desc captured

Specific for CUA systems:Note 1814400 - Decentral call is opening different session in CUA

(Documentation provided by:Guido Stusinsky)

Common Issue: Logon screen appears when starting FF session

It's possible that we get a logon screen after starting the FF session. This is an incorrect behavior since the user doesn't need to enter the FF ID password.

Here some tips:

Check the RFC connection. Perform an authorization check in SM59 to check if the RFC user is OK.
Check that the RFC is pointing to the correct client.
Look for dumps in ST22 in the plugin system.
Check if the FF ID password is productive, reset the password or check with changing the user to type "Service" if you are using "Dialog" user for FF ID.
Have a look at the following notes:

1861981 - Things to check when error message 'Error in opening RFC destination' appears in GRAC_SPM

1777094 - EAM log on is not possible with the error: 'Error found in RFC (plug in system) and respective logon\logons are disabled'

Note 1886332 - GRC 10.0 EAM prompts for user/password while logging

Note 1872709 - Logon popup shown when launching the EAM session

Co-existence of firefighting models

Both models could be used. The decentralized firefighter configuration doesn’t block the centralized firefighter approach. Since you can start only one firefighter session at a time, you cannot use both at the same time and this is automatically controlled by the application.

Administration functions

The administration functions are maintained in the GRC Box. The decentralized firefighting adds a couple of tasks in the plugin system such as logging notification customizations and the possibility to extend the validity date of firefighters if the GRC Box is down. You’ll find a nice illustration in the guide attached to note mentioned earlier (1690964).

Access to decentralized FF

Some standard roles do not include the correct SPM transaction. In order to start decentralized FF the Firefighter user have to type /n/GRCPI/GRIA_EAM in the transaction bar. If you use other tcodes might see an empty table, and if you don't use /n you'll receive a message stating something like it's impossible to execute this function.

Please share your thoughts, comments or documentation in order to improve this guide.

Well, that’s all. Hope this document has helped you to successfully configure GRC EAM.

Cheers!

Diego.

GRC 10.1-Governance Risks and Compliance

Pages