who does Role Design in SAP

[Former Member]

Hi Experts,

Please let me know who does role design in SAP? I mean who is responsible for role designing in an SAP implementation project? Whether he is BASIS or Functional consultant.

<removed_by_moderator>

Thanks,

Sudip...

Edited by: Julius Bussche on Apr 10, 2009 9:08 PM

[jurjen_heeck]

The SAP Security Consultant of course. Who else?

[Former Member]

Hi Jurjen,

Yes, the basis or security person is responsible to create role in the system using pfcg. But, in an implemantation project when the business desides to create some role for a particular module (eg, SD, FI or MM) then how come the basis or security consultant will know the authorization about the particular module's tcode? So, functional consultant will design the role like what access needs to given to the particular module user. Functional consultant of that module will prepare authorization sheet for his module and at last the sheet will be given to BASIS or security consultant to create the role in the system.

Hello Experts, am I correct? Please let me know your valuable opinion.

Thanks,

Sudip

[Former Member]

best practice:

1 the functional consultant (together with the business key user or how they call it) describe the processes to the task (=Transaction) level.

If the functional consultant is experienced they will know that they also should deliver a functional description of the risks in each task and what should be restricted from certain users

2 the security consultant (and absolutely NOT the basis engineer) will translate the outcome of 1 in a roles design.

3 the functional consultant should test the roles if they are created as described in point 1.

Most commonly forgotten: A processed in point 1 does not have a one to one relationship with a role that part of the design involves the user mapping to the tasks!

As in a lot of implementations companies do not want to spend much mony on the above you see a lot of fiddeling around. Result is that after a while the company gets stuck with their roles design and have to spend a lot of mony on redesiging all! This usually costs much more then when done good initially.

[Former Member]

>

 But, in an implemantation project when the business desides to create some role for a particular module (eg, SD, FI or MM) then how come the basis or security consultant will know the authorization about the particular module's tcode?

It is the role of the security consultant to understand how the restrictions available for a module work.

[Former Member]

Dear Sudip,

Obviously role designing will be done by Security Consultants. But at times they can even involve the Functional Managers as well in discussions for better designing.

Regards,

[Former Member]

There is no 'correct' answer for this as many companies are different and work in different ways.

Generally a security resource muct be involved, along with the functional team and business process experts. Often organisational design teams and risk management/controls teams will be involved in the process of role definition.

From a technical perspective, the design should be solely the responsibility of the security practitioner.

[Former Member]

> Whether he is BASIS or Functional consultant.

Actually the person who develops the application, according to it's various requirements, should develop the roles to use the application... so it is the DEVELOPER as well.

At the very least, if the use of the application is dependent on it's deployment, then the developer should develop "standard" roles as a suggestion or templates for it's use. These can then be copied and tweaked further.

If the application is cross-component or cross-system and configured via an installation wizard, then 9 times out of 10 it is better to create a profile to assign via the user interface for it... and not a role which can be screwed up by a fool.

Having said that: if folks know what they are doing and stick to the concept... then you can also use roles and the objects which control maintaining them. You can also control the user groups.

If the Security Concept Designer does not communicate a useable design and rules for the developers (of the config, the programs, the roles...) to stick to.... then it soon does not matter whether you have a design or not...

Organizational discipline and layered release strategies is the key if you want to achieve security in SAP systems...

My 2 cents,

Julius

[Former Member]

Step1

Business & functional will design the business profiles (T-Code& activities)

Step 2

Security will design naming conversion for the particular role &SOD Check QA clearances

Step3

Basis has to create the role and assign to users.

[Former Member]

just as i described, but with ONE exception, step 3 should be done by the security consultant as that is were the security expertise is and should not be left to basis!!!

[Former Member]

>

> Step1
> Business & functional will design the business profiles (T-Code& activities)
> Step 2
> Security will design naming conversion for the particular role &SOD Check QA clearances
> Step3
> Basis has to create the role and assign to users.

Many security consultants perform step 1 with business and functional teams. I would say that in many cases, a security consultant who does not have input in Step 1 is not performing the role that they should do.

[sdipanjan]

Hi,

I believe, this can't be answered in this type of spaces. But I can give you the address where you can get the answer. Please go through ADM 940 (AS ABAP Authorization concept). You should also consult "SAP Authorization Concept" (SAP Press Book) to get the process model (ASAP method as well as IBM Phase Model).

And last of all, the Role structure can't be designed by SAP NW Admin (BASIS) or by Functional consultant. It is the responsibility of NetWeaver Security administrator. But, there is a need of Functional consultants of all areas to find out the list of TCodes and Access (by taking SOD into account) for each Position.

Regards,

Dipanjan

[Former Member]

Hello All ,

Designing of roles in an new implementation is done by all Securty Analyst by coordinating with all the Project teams involved in the implementaion , User Departments and and Business Unit of the implementing company.

After co-ordinationg with all these teams and gathering all teh specifications then security analyst start begins to desing and implemention the roles.

Kindly go through the concept " Create and Implementing Authorization concepts " in ADM 940 book. This gives you about complete picture.

Regards

Kanti

[Former Member]

ADM940 (and the other books) suggest ways that you can do it, this is not set in stone and there are things in there (composite roles for example) which are dependent on many factors.

Generally the proposed methods are task based as this fits with ASAP, there is a lot of benefit in doing your analysis at the level above.

[Former Member]

Hi Alex ,

Composite role scenario is completely different. This comes into picture after complete design and implementation of single roles. This again depends on what scenario does business wants to go with. If the buisness not much complex scenario and very few job positions or roles then composite role approach is not suggestable and is very cost expensive.

Initially when we business is going for new implementation for the first time security analyst has to coordibate with all project teams, user departments, and business units before getting start with design phase of authorizations and once after all the roles are designed and approved by the business then the actual implementation phase begins where security analyst decides the techinal namimg convention for the roles as SAP standards and creates the roles as per the role matrix that is designed earlier.

That is why recomended that Security Analyst should be invloved right from the Blue Print phase in the ne business implementations.

Regards

Kanti

[Former Member]

Hi Kanti,

Composite role scenario (as an example) is certainly not different. The technical decisions need to be made in parallel with the role design or you end up with a very compromised security design.

By leaving the technical interpretation of design until after the design and approval, you end up in the suituation where security is a reactive team who builds what they are told to rather than having input into the design. Users do not work in single roles, they work in functions and jobs and this needs to be addressed at the same time as defining the tasks that are performed for each process.

The "single role" mindset is there to make things easier for the functional and process teams. The task based approach mimics ASAP and some other consulting firm methods of process design. From a security point of view there is a separate level of analysis which needs to take place. This is often skipped because security come in too late and don't have the business process knowledge to do the work. Using composites is an example where this work is skipped.

You would not allow a business to design their business processes in isolation and then tell the functional team to implement those, it needs to be done in parallel with a thought to what can be done technically.

I'm with you that security needs to be involved in day 1, maybe we have different ideas about what security should be doing at the time? In the grand scheme of things I would much rather security focussed on on providing design input at the early stages with a view to what they need to implement.

Cheers

Alex

[Former Member]

Hi Alex ,

I was not saying that business will design their processes in isolation and then fucntional team will implement that.

I am trying to say that business , functional and technical will together integrate in defining the processes as per the requirements of the business and this is done during the design and analysis phase.

Yes you are correct users work in functions and jobs and this needs to be addressed at the time while defining the tasks that are performed for each process.This job is nothing but the role which describes the postion and function of the user what he performs in the business. That is where the single role comes into picture. Composite role scenario comes into picture where there 2 different job roles 3 different users A, B and C where user C belongs to both the job roles then instead assign user C to individual job roles separately we will have one composite role which contains these two job roles and will assign user C to this composite role. Advantage of having composite roles is to avoid buffer problems with the user profiles.

That is why I have said that composite role scenario will be decided based on the business size and requirement and and no. of job roles involved in the business.

Regrads

Kanti

[Former Member]

Hi Kanti,

During this design and analysis phase, security also need to be providing their input and working on their technical design too. Security and controls is as relevant in analysis & design as BPP's are.

From what you are saying, I get the impression that you support 1 composite role per user? How will this avoid user buffer issues? Irrespective of how you assign roles to a user, the same number of authorisations will be loaded into the user buffer. If you are anywhere near limits for the user buffer then immediately it can be seen that the security technical design in compromised because security did not provide input at the relevant stage.

You could assign 10 identical roles but only 1 profile will be loaded. Furthermore, the more single roles that you have, the more duplicate objects/values you will have. Designing as close to the Job as possible (Job in SAP being all the access a user needs in SAP to perform their functions) reduces duplicates, increases simplicity in allocation and administration etc. While I think that we divert very much from the original topic these are the design decisions which security need to be involved in right from the start. Building lots of single roles and then bundling them together makes sense to make things happen quickly and doesn't require security to think, yet they have to bear the increased support workload later on

Cheers

Alex

[Former Member]

Hi ..

Role designing is the responsibility of SAP Security Consultant .Basically what are the requirements of business users or what access business user needs that will taken care by functional consultants and then functional consultant translate it in techinal langaugae to SAP Security consultant who are desiginign the roles.

Hope this suffice you .

warmregards

Vikas

[Former Member]

Vikas

i absolutely do NOT AGREE on one point the translation from functional to technical is the expertise of the security consultant

IF HE CAN NOT DO THIS HE SHOULD NOT BE IN THAT JOB!!!

But start learning!!

[Former Member]

Hi Auke

Can you please clarifiy me whats the difference between System Analyst and System Architect ?

System Analyst (In this case,Funcional Consultant 😞 Understands the requirement of business users /End users .

System Arhitect (In this case,Security Consultant) : Designs the things (in this case roles ) with the help of System analyst .

Failure to implement /design roles is a management control failure .!!!

If you came to know about the difference then You will understand how the functional consultant understands the Business users needs and then with the help of Functional consultant Secuirty Consultant desgining the roles .

Hope this suffice ..

Regards

Vikas

[Former Member]

It all starts with a good understanding by the Functional consultants what products we expect from them!

I always tell them : i want a process design on the level of tasks (= transactions) including a functional description of the risks they see in each task.

If I have to work with inexperienced functional consultants I always offer to help/guide them how the product should be delivered.

I do have a lot of roles as build in other projects in my baggage, but i never volunteer to give them into a new project as you will soon discover that they are not fit for purpose for another company. What I do is compare the new design with other roles I have build in the past and then go back to the Functional consultant asking why they did not add transactions u2026u2026 mostly we find then that they forgot these etc..