cancel
Showing results for 
Search instead for 
Did you mean: 

ITSM & ChaRM Security Approach

former_member275658
Contributor
0 Kudos


Hi Gurus,

I am new to ITSM & ChaRM security. I have read lot of documentation about this but We don't want to use the standard template roles for ChaRM provided by SAP. We would like to customize roles from scratch based on testing/trace results to get accurate security access (no more or less access),

Is this a good approach ? Which approach is normally used by companies whether they just copy standard roles and implement ?

also, do we need to create business partner for all end users who can create support message?

Regards,

Salman

Accepted Solutions (0)

Answers (3)

Answers (3)

former_member275658
Contributor
0 Kudos

thanks Andrey and Thorben.

Andrey - We have a scenario where End users won't create incidents from solman but through satellite system via "Create support message" then our support desk team (Level2) will use the incident number and assign it to the team and support desk team can also create incidents directly through solman(so support desk team would definately need user id in solman and bp).

Thorben - I am thinking of creating one single role per function group (like Change manager). Probably, I will end up creating not more than 6 - 10 single security roles per our function groups.

  

1) End-User
REQUESTER - who creates ticket - this is by default already there

2) Support Desk
(2nd level support) - who receives the ticket first or creates a new ticket and
assigns Support team

 

3) Support
Team/ Message Processor - who process ticket and create Change Request

 

4) Tech/Dev   - who updates Change Request with estimates, assigns
developer etc. and sends it for approval - possibly CHARM
CHANGE MANAGER without Approval capacity??

5) Business
Approver (NOT a CHANGE MANAGER) - should only have Change Request approval
authorizations

 

6) Developer -
as SAP defined

 

7) Tester - as
SAP defined

 

😎 Operator/Basis - as SAP defined

9) ADMIN - Together IM ADMIN and CHARM ADMIN

0 Kudos

I'm talking exactly about scenario when end users create incidents from managed system via "Create support message" button, not in SolMan. To do that they must have authorization in SolMan, because in this time managed system connecting to SolMan via trusted RFC under current user and creates incident using his authorizations.

About roles. Due last project we used this approach:

1 composite role for each function role (Requester, Support Desk, etc.)

1 single role for each finction role (Requester, Support Desk, etc - ABAP authorizations for specific for role statuses, texts and transaction types)

1 single role for each CRM business role (linked with SOLMANPRO, SOLMANREQU, etc.)

1 single role for general CRM WebClient UI authorization (general UI components - role have to be included to all composite roles)

2 single roles for general ABAP ITSM or ChaRM authorizations (for example: display all scenario transaction types - each role have to be included to only ITSM or ChaRM composite roles)

2 single roles for general CRM WebClient UI ITSM or ChaRM authorizations (scenario UI components - each role have to be included to only ITSM or ChaRM composite roles)

Then we were combining 5 single roles into 1 composite roles for each function role.

Customer looked happy.

Andrey

former_member275658
Contributor
0 Kudos

thanks Andrey for sharing your expirience.

Did you copied the standard roles or built it from scratch ?

As per our security policy, we can't use composite roles.

Former Member
0 Kudos

Hi salman

If u run solman_setup in solman, you can copy all the sap std roles to custom , which u can use it as single role and assign to respective users.

Thnx

former_member275658
Contributor
0 Kudos

Hi Jignesh, We don't want to copy standard roles as we have customization. Need to build roles from scratch by tracing

0 Kudos

Hi, Salman!

Described approach is good because most types of roles have analogs in set of standard roles, like role for business roles and roles for CRM WebClien UI.

To build general ABAP role for IM or for ChaRM we copied one of standard role which had enough authorizations (in our opinion) and delete objects B_USERSTAT, CRM_ORD_PR, CRM_TXT_ID, B_SMAN_WPL, etc. These objects then were added to new single roles with individual values for each function role. It is not too difficult if you have experience on SolMan role customizing. In another case tracing can be more useful.

Andrey

former_member275658
Contributor
0 Kudos

Great Thanks Andrey. I have a security approach meeting next week. let's see how it goes.. I will keep this post open so I can share the outcome

velden_thorben
Explorer
0 Kudos

Hi Salman,

i would recommend to use STAUTHTRACE on a user with SAP_ALL (non-productive environment of course), do the desired actions and derive the roles you need out of the trace. Copying is never enough because of the customer settings in the workflow, especially when you have a lot of customization. For each status in your workflow(s) to be set a special authorization is needed.

I think a good approach is to define roles for each status and wrap group(?)-roles for workflow-partners (e.g. Author, Developer, Change Manager) around them.

Regards

Thorben

0 Kudos

Hi, Salman!

Different customers use different approaches. It depends on internal security policy.If customer has obligatory requirements for SAP roles (restrict/regroup/rename), you have to follow them. If customer do not specify requirements for SAP roles it would be better to use standard roles copied to Z.

Yes, you have to create business partners and users in SAP Solution Manager for all end users who will create support tickets. Use transaction BP_USER_GEN for this.

Andrey

former_member275658
Contributor
0 Kudos

We do have lot of customization in Itsm and charm that is why we are thinking to build roles for each function from scratch. Is there any issue or risk with this approach?

Alse why do we need all users created in solman for bp. I was thinking end users should be able to create support messages without going to solman and without bp.

I Agree if the end user has to create ticket from solman then they need business partner assigned.

0 Kudos

In this case I wouldn't remake roles.

Your end users must have users in SolMan. If they haven't users, they will not be able to create incidents, because system uses trusted RFC from managed system to SolMan for this purpose. However, if you change trusted RFC to another one with predefined user (table BCOS_CUST in managed system), your end users will be able to create incidents without users in SolMan. But then you can't understand, who of them created incident.

You will face with same problem if your end users don't have BPs, because after creation of incident field 'Author' inside it will not be filled. I think it is little uncomfortable for processors.

Andrey