why do we need Profiles ?

[Former Member]

Hi all,

I know it a bit stupid question you would think but do read it complete before answering.

1. When we create a role the role name is given and tcodes are assigned to it.

Then we go to the authorization tab, before that it asks us to save the role.

So the function of the role is only that much ? .

2. Then we go to the authorization tab and then go to generate profiles. It pulls the authorizations and authorization profiles for all the objects in a role.

Now my question is :-->

Why SAP needed to maintain roles and profiles separately, whereas it could simply have a single activation button as we have in ABAP in authorization tab which would pull the authorization into the objects ? That would not generate any profile and we need not maintain tables related to Profiles.

NOW PLEASE DONT ANSWER THAT WITHOUT PROFILE ROLE IS OF NO USE.....TILL WE DONOT GENERATE THE PROFILE WE CANNOT USE THE ROLE.

hope all have understood my question if there is any doubt let me know.

[Former Member]

Hi,

Profile is a kind of "security filter" - only technical setting are there.

Role is a next level of security definition :

it adds "personalisation" level to security concept (menus, mini apps).

It allows you to "granulate" your secuity definition by using composite roles - roles including other roles (there is no such possibility in case of profiles)

Regards,

Wojtek

[Former Member]

> It allows you to "granulate" your secuity definition by using composite roles - roles including other roles (there is no such possibility in case of profiles)

Hi Wojtek,

Composite profiles have been used for ages. Check out SAP_ALL in SU02 as a well known example.

I would say that composite roles are but a single (ugly) tool for allowing you to "granulate" roles.

[jurjen_heeck]

The profiles hold the actual authorizations which are checked in the software (by the AUTHORITY_CHECK statement).

The roles are a sort of building and administration aid.

Apart from that, as Wojtek points out, the roles bring along additional functionality which has no influence on the actual authorizations.

In earlier versions of SAP (as I've been told, my experience starts at 4.5) the profiles were maintained manually, which was not an easy task.

Nowadays the role concept (started from activity groups...) makes authorization maintenance a lot easier. More intuitive interfaces etc... underneath these lies the original profile concept. As you can guess it is nearly impossible to chuck the whole profile concept overboard and replace it with roles as this would not only mean rewriting the statement AUTHORITY_CHECK but also debugging all programs in the system. Backward compatability can be a good thing.

So, think of the profile generator as your nifty toolbox in which you can click all requirements together and, once satisfied, hit the button that does all the boring stuff (creating the actual profile) for you.

With this I do not really understand the second part of your question as it is only the role you have to maintain. The profile is generated at the push of a button.

Hope this helps

Jurjen

Edited by: J. Heeck on Jan 2, 2008 12:06 PM

[Former Member]

Hi,

The profiles are the technical part of the authorizations that exist a long time already. In 2.c it was only profiles and no profile generator. With the profiles the userbuffer is completed when logged on to the system with all authorization objects and values. This is SAP way of working from the beginning with R/3. The profile generator is just the describing part and uses information from tables(see transaction SU24). It is a lot easier than finding out all by yourself, looking in abaps, tables and tracing. You must see it as the describing part (PFCG) and the technical part. I think it was easier for SAP to take this actions with the profile generator, than redesign their authorization solution.

Have fun

Jan van Roest

[Former Member]

Thanks for the replies.

One more question :--> Is it that like we have a compilier in C++ and other languages ...in the same we have profile generator in SAP.....and Kernal of sap understand only the profiles and no roles .....and roles are built only for human interaction............

I am only trying to corelate it .....correct me if this is wrong../......

Is it that in the start there were only profiles and no roles.......?

[jurjen_heeck]

The analogy with compilers is a bit too much for me as the profiles are still readable for humans (and were maintained by humans in the older SAP versions) but for your final question:

Yes, SAP R/3 started with profiles only.

Roles were added later to support additional functionality.

[Former Member]

It goes even deeper:

In the beginning there were profiles only, and were maintained by Basis admin.

After a while it was found that most basis admin did not care about really securing the system with all possible options. So another kind of people was needed to build and maintain security in SAP.

This new kind of admin (security administrators) originated from the function that was best equipped for applying the right level of security => finance.

However the technical knowledge in these people was limited so the profile generator was build (R/3 Release 3.1H the first mature version), and as already mentioned this is ONLY a TOOL to build profiles.

It is still possible to build profiles directly and to assign this to users. Although I have never come across a valid reason to do that!

Later additional functionality f.i. workflow was added to the profile generator.

Edited by: Auke Visser on Jan 2, 2008 4:14 PM

[WolfgangJanzen]

>... ABAP kernel understands only the profiles and no roles

> ... and roles are built only for human interaction

Like this, it is stated correctly.

Yes, at runtime the kernel only evaluates profiles (and authorizations) but no roles. However, roles are the recommended method to assign authorizations (and menu items) to users. The role concept was introduced with the SAP Workplace (4.6C); prior to that, "roles" have been called "activity groups".

[Former Member]

Hi Rajesh,

Roles (as described by Auke) are just a tool on top of the user's authorizations, which an authority-check then sets a return code for.

What the calling program is and what it does with the return code, are "the other half of the coin" in both cases (profiles (and authorizations) or objects (and authorizations), but no roles).

You can in fact even substitute "Roles" for other tools (not recommended though), but you cannot substitute profiles and authorizations because your ability to change the authority-check is rather limited...

Kind regards,

Julius

[Former Member]

Hi,

A role is just a collection of profiles. The profiles contains auths, which plays a vital role in granting access for the particular tracsaction for the user.

[Former Member]

>

> Hi,

>

> A role is just a collection of profiles. The profiles contains auths, which plays a vital role in granting access for the particular tracsaction for the user.

Roles are more than a collection of profiles.

As Wolfgang pointed out you can create menu structures in roles which is not possible with profiles. You can also add stuff into the menu that is not held in the profile such as URL's, Queries, BW reports etc.

[Former Member]

I think the main point is that Roles provide user menus, making it easier to train users, and display users job tasks only, rather than using the entire SAP standard menu when users only perform a small set of tasks. Each Role has a unique 10 digit (or 12 digit from the kernel view) generated profile that the system uses to reference the authorizations in the user buffer. These technical named combination of authorization objects and values are used by the authorization checks, but are directly related to the role, there are clean up jobs that compare role assignments and profiles assigned to users and the system will remove profiles from a user if it does not find the corresponding role, therefore they must both be assigned to the user and it is no longer supported to create and assign profiles only, (though technically possible)