Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Difference between Role & Profile

Former Member
0 Kudos
3,294

Hi

I created users through SU01 and assigned the profiles e.g SAP_ALL, SAP_NEW etc.

When i created profile using profile generator and assign, it assign to Role & Profile .

Can you please clearify for me the concept beteen Role & Profile

Thanks

12 REPLIES 12

Former Member

Former Member
0 Kudos
231

Access (values for auth fields of objects) is in both cases granted via profiles (key fields of usrbf2).

The roles of PFCG are just a tool ontop of profiles which generate them and associate them to the role. When you assign a user to a role, PFCG will technically assign the generated profiles to the user, not the role.

0 Kudos
231

Hi, I need to disagree. Roles are definitely the way to go!

Profiles used to be created manually: Authorization objects, which are checked in the code of programs / transactions, were manually added to profiles and the profiles were directly assigned to users.

This approach has a problem: How do you know which authorization objects are needed by which program / transaction? That is one reason why there are still so many SAP_ALL users.

Today, roles should be created by assigning transactions to the role via the SAP menu (see PFCG). The required authorization objects will then be automatically added (which objects are needed by which transaction is maintained in SU24). Technically, one or more profiles are "generated" for each role. Also, when assigning roles you explicitly also assign the generated profiles to the user master.

Generally: 1. Do not use SAP_ALL users in productive systems. Auditors do not like this. 2. Do not directly assign profiles to users. Always assign roles.

A good point to start learning more about authorizations is "Authorizations Made Easy". You can find a link to it here: <a href="http://www.sapsecurity.net/securitydocs.htm">SAPsecurity.net</a>. Another point to learn more about SAP related security and risk management is "SAP Security and Authorizations, which you can get through <a href="http://www.amazon.com/gp/product/1592290620/sr=8-1/qid=1153742104/ref=sr_1_1/104-5471209-9051146?ie=UTF8">Amazon</a>.

Cheers,

Christian

0 Kudos
231

Hi,

I definitely agree with Christian here. Roles are the way to go. We have SAP since '98 and most of the Security started out with profiles and its a mess maintaining it.

Creating and assigning roles is much better and maintenance is less painful. Also, in the long run, profiles will also land you in trouble with the auditors if not maintained correctly.

I'm also surprised that you were able to get clearance for assiging SAP_ALL and SAP_NEW powerful profiles to users in Prod with all the SOX-SOD stuff that goes on today.

Also, profiles will be a problem during upgrades, trust me as there is no utility to convert them except manually. Also the compexity of your Security design will have be taken into consideration. With roles this aspect of it becomes simpler.

Cheers,

Kedar

0 Kudos
231

I am not advocating the use or assignment of manual profiles. I was answering the question on what the difference is.

For me roles are a tool on top of profiles to ease their creation, administration and assignment to the users. It also makes the concept "understandable" for a role owner from the business when the role is called "FI_AP_Display and Reporting". I agree, it is the way to go!

A problem with roles, which the auditors and many customers seem to be oblivious to, is that rarely are the implementation instructions followed when switching from manual profiles to generated ones. That would be my experience. Some of them say that it would be "changing SAP standard..."

Are there any reliable statistics available on the use of SU25 / SU24?

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos
231

Please abstract from implementation details.

Currently, at runtime only the profiles (and contained authorizations) are 'visible' (to the kernel). That why the "profile generator" creates profiles out of roles.

But this might not remain unchanged forever.

Role-based concepts are definetly the better choice - and will continue to exist in future (keyword: RBAM - Role/Rule-Based Access Management). The future of profiles is unclear (only for the sake of downwards-compatibility they might remain).

Best regards, Wolfgang

0 Kudos
231

This message was moderated.

Former Member
0 Kudos
231

Hi Juan,

The Simple answer is :

Roles and profiles are literally same.The only difference is using profile we canu2019t restrict a user up to activity level whereas we can do so using roles.

0 Kudos
231

> The Simple answer is :

> Roles and profiles are literally same.The only difference is using profile we canu2019t restrict a user up to activity level whereas we can do so using roles.

It may be simple but it is completely incorrect.

0 Kudos
231

Lovely old thread...

As Wolfgang already indicated way back when... profiles are destined for potential obsoleteness.

SAP has long been advocating not to use profiles (except the generated ones). UME's pointing to ABAP systems don't use it either for some time now.

Since release 46C the new buffering method already supports authorizations only, or permissions...

All it needs is a tool ontop of it for creating them, administrating it and assigning them in the various component systems => e.g. centrally in an IdM...

I think the importance of meaningfull role naming conventions and the S_USER_OBJ, VAL, TCD will play a more meaningfull "role" as well, also for security admins.

SAP seems to have been conceptually lining up for this in the ABAP stack, as it will no doubt play an important role as the user store for the component systems.

> It may be simple but it is completely incorrect.

Perhaps even completely obsolete.

I have also noticed some of the technical settings changing in the USR* tables, in addition to their fields and their keys, in the latest releases.

Cheers,

Julius

0 Kudos
231

This message was moderated.

Former Member
0 Kudos
231

This message was moderated.