why dont SAP device a fullproff mehthod for authorization

[Former Member]

why dont SAP device a mehthod that can make taking the authorization object and related field value easy.

Useing trace and debuggers are not ment for this purpose . These are just work around.

It is very tedious seaching all object related to tcode in Tx su24.

Using all this work around done not garentee 100 % results .

Also SAP has very little litrature FREELY available for implementing authorizations ( articles , blogs , documents, notes, how-to ).

TADM940 , TADM950 gives a technical info on the authorization system SAP has developed and how it works.

One more apportunity SAP had to help this cause was solution manager . Using BBPs it could be very easy for system to generate the autorization matrix and related implementation activies.

SAP did not take it up.

There is no such tool that can help in all task for implementing authorization. I am not aware of any 3rd party tools but I am sure there ll be many tools developed to take advantage of this situation.

P.S:

Moderator: I had to ask this as a seperate Question to know if I share the same views on the authorization as others .

[Former Member]

> P.S:

> Moderator: I had to ask this as a seperate Question to know if I share the same views on the authorization as others .

No problem. Should be an interesting discussion...

For a start, there are blogs and articles on this. Take a look in my business card: Alex Ayers and myself wrote one a few weeks ago, and there are more. My experiences with SAP are also that they appreciate any feedback and suggestions, if you speak to the correct people.

Kind regards,

Julius

[Former Member]

Hi Hussein,

Interesting to hear your thoughts on the subject, I think my opinion differes slightly

Auth concept is complex as is what it is restricting. From an application security perspective it is also a better mechanism (in my opinion) than the other ERP solutions out there. Better field level restriction would be very useful but I can also see the situation where it would be abused and lead to an over-complex design. Use of authorisation variables as in BW would also be an interesting development especially in areas like CO module.

By thinking in terms of data & functions rather than transactions, the auth concept makes more sense and allows us to control access to these functions regardless of the way we access these functions (usually).

Debugging isn't good but how often do you really use it? I can't say I have to use it that often. Trace is different is is very much designed for the purpose of working out what auths are checked when running a transaction in a particular way with a particular set of data.

SAP has a huge amount of FREE data. I can say with confidence that the freely available material is in more detail than the ADM940/50/60 courses. All you need to do is spend some time looking for it - most of it is in the security guides section.

I personally don't like the idea of a tool automating the build from BBP's because that gives no discretion in the method of build, which has a huge impact on management & maintenance of a solution. Security is not a push button exercise and should not be treated as such. It is evident that there are many people working in the security field who, with the same level of knowledge, would not be permitted to work as a functional consultant. Dumbing down the technical side of this would only make this worse in my opinion

Cheers

Alex

[Bernhard_SAP]

Hi Alex,

do you have some expirience with the Virsa-Tools? Maybe for instance the 'Role Expert' gives better assistance already than the old standard tool (pfcg)....

b.rgds, Bernhard

[Former Member]

Hi Bernhard,

While not an expert user of Role Expert, there does seem to be some interesting functionality there from what I have seen from it.

I like the concept of automating derived role creation via applying Organisational Data Sets to create the variants. It certainly could save a lot of time!

From what I have seen so far of RE other tools such as the one from CSI (licenced by SAP now I believe) they are facilitators rather than forcing you to design in a particular way which for me at least is attractive.

[Former Member]

One thing to remember SAP security is a specialism one can learn (and not by attending one or two courses but after a long time on the job).

The complexity comes primarily from the request of customers over teh years that want to be able to restrict on a specific item/field.

To look at it from a technical point of view only (create a tool) is bypassing the complexity one finds in companies that have (and want to keep) a certain way of working still being able to meet SoD and other security requirements.

And the later is the main focus of the security consultant and I am sorry to say that I have met a lot of consultants who have no clue how to do this. A large number of them do not think any further then how to solve issues technically!

So do not complain, learn the Job and become a good consultant

[Former Member]

>One thing to remember SAP security is a specialism one can learn (and not by attending one or two courses but after a long time on the job).

>The complexity comes primarily from the request of customers over the years that want to be able to restrict on a specific item/field.

>To look at it from a technical point of view only (create a tool) is bypassing the complexity one finds in companies

I completely agree that SAP application security in place is very complex and efficient. And it is required to have the complexities to be so much effective... And saying that I understand making a tool for it will be a herculean task. But after all thatu2019s what SAP is known for.

The Point here is not about reducing the complexity or efficiency of actual technology , Itu2019s about making the means of implementing it more approachable. You always have the option of going back to old methods to implement complex authorizations if and when we have new tools.

A security expert require process knowledge agreed but that does not mean that he is not entitled to have a tool that can make it job more approachable and time effciant.Tool only enhances your abilities but dose not replace the knowledge that one needs to have.

> Security is not a push button exercise and should not be treated as such.

There is no such thing possible in any area. But then too SAP gave Functional consultants the advantage of predefined BBPs in Solution Manager. That does not mean that BBP definition is now a push button job. Still the BBP needs to be tuned, customized, changed and alter according to Customers scenarios. Also new BP needs to be developed.

Same goes with the Authorization Implementation. I know SAP has similar thing for authorization i.e. Predefined

roles. But that is not at all sufficent.

>By thinking in terms of data & functions rather than transactions, the auth concept makes more sense >and allows us to control access to these functions regardless of the way we access these functions .

I totally agree with you on this. Functional people are suppose to give requirement in relation with tcodes (mostly). But the issue here is the mapping from the functional (data level) to technical .It evntually required digging down all objects and field level activies and then testing it. The so called "Trial and error mehod" . So a good technology for this purpose is nice to have or should I say much required.

>SAP has a huge amount of FREE data. I can say with confidence that the freely available material is in more detail than the ADM940/50/60 courses. All you need to do is spend some time looking for it most of it is in the security guides section.

About FREE material in security guides I have gone through almost all of them. Mostly all of them cover topics other then application security (authorization) .We have book like HR940 and BW940 these are good books. But books like these are somewhat discretion of authorization object. But what about SAP Central Components. The guide just lists all available roles and profile for all modules. Though again I will try to explore new material if available.

[Former Member]

>

> I completely agree that SAP application security in place is very complex and efficient. And it is required to have the complexities to be so much effective... And saying that I understand making a tool for it will be a herculean task. But after all thatu2019s what SAP is known for.

The current tools we have available are reasonably effective giving a combination of ease of use (role menu's SU24 etc) vs flexibility (very granular auth concept). There are improvements which could be made and there are products existing or being developed to address this in some cases.

>

> The Point here is not about reducing the complexity or efficiency of actual technology , Itu2019s about making the means of implementing it more approachable. You always have the option of going back to old methods to implement complex authorizations if and when we have new tools.

Implementing it is reasonably approachable for anyone with the skills to do it.

In the most basic case you can teach someone with no prior knowledge to create roles & users in 3 days, try doing that with Basis, ABAP or functional config for people with no contextual knowledge.

>

> A security expert require process knowledge agreed but that does not mean that he is not entitled to have a tool that can make it job more approachable and time effciant.Tool only enhances your abilities but dose not replace the knowledge that one needs to have.

In the security market such a tool would be seen as a replacement for experience or resource. There are many security solutions out there which would not be tolerated as a functional solution. Look at GRC from SAP. There are people with poor controls & security knowledge implementing a product and calling themselves GRC experts. They have a tool which makes it much easier to perform SOD checking but they do not know why they are configuring it or what to do with the copious default output they get from it. Companies spend lots of money on licences for a product and skimp on the implementation because it is seen as purely an installation exercise to get it in place & get the benefits from it. The best of both worlds would be installing these tools and then doing the hard part of implementing them and getting them working properly using people who know what they are doing and why they are doing it.

>

> There is no such thing possible in any area. But then too SAP gave Functional consultants the advantage of predefined BBPs in Solution Manager. That does not mean that BBP definition is now a push button job. Still the BBP needs to be tuned, customized, changed and alter according to Customers scenarios. Also new BP needs to be developed.

> Same goes with the Authorization Implementation. I know SAP has similar thing for authorization i.e. Predefined

> roles. But that is not at all sufficent.

There is a good reason why many implementations do not use the BBP's or functional roles - they do not represent what they company needs or does. Bodging these to fit your scenario will never be as good as developing yours to meet the requirements you have which include organisational, compliance, support etc.

>

> I totally agree with you on this. Functional people are suppose to give requirement in relation with tcodes (mostly). But the issue here is the mapping from the functional (data level) to technical .It evntually required digging down all objects and field level activies and then testing it. The so called "Trial and error mehod" . So a good technology for this purpose is nice to have or should I say much required.

The technology is a combination of knowledge and ST01, ST01 is the tool to help when the knowledge fails. SAP delivers some check indicators which may or may not be relevant depending on data used, path through a transaction, configuration. To have a system which dynamically responds to this would be so complex that it would have more bugs than it fixes.

>

> About FREE material in security guides I have gone through almost all of them. Mostly all of them cover topics other then application security (authorization) .We have book like HR940 and BW940 these are good books. But books like these are somewhat discretion of authorization object. But what about SAP Central Components. The guide just lists all available roles and profile for all modules. Though again I will try to explore new material if available.

There is more info in the following link, F1 help & SU21 than there is in ADM940/50/60

https://websmp202.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000401180&;

[Former Member]

I would like to point out that we should split this discussion in Technical and Functional.

Technical: a tool is handy, but we survived a long time without, using standard MicroSoft tools/programms and SAP tools like CATT, SECATT and LSMW. Advantages, you can adjust it yourselve.

Functional: although one can start using roles from previous (other) implementations (or even companies) in the end of the day teh company you currently work for is organised differently and needs different roles, so no standard tool could fit that!!!

[Former Member]

Good point Auke, I agree about the functional part. A tool which dictates what and how you should build is. in my opinion, always going to be very flawed. Speeding up our implementation of the technical side is a bit more helpful.

[Former Member]

SAP has been know for its strong application security. No arguments on that and I am not at all challenging it. And the fact that it has been successfully been implemented over the years, it speaks for itself. So we donu2019t need to defend its tools or technology.

I sorry for blowing this out of proportion as much as it looks like a essay or a blog rather then a post . But cant help had to share this will you people. I have to put forth what do I mean when I say u201C A better implementation toolu201D. I know it may have many flaws and pit falls but still its just a rough idea.

What I have writen may sound to be tooooo ambitious but worth giving a though. If not completely it may be pragmatic in part.

The primary focus as a tool for it is Solution manager, as it is the idea componets for it. It will explore the potential of Solman as it is connected to systems across landscape. Here solution manager will not only help in to gathering and accessing Authorization documents (requirements , technical and implementation) all at one place but also materializing the authorization requirements. So all authorization task will be performed in solution Manager.

The Main idea is to have a Tx (Program) in Solamn similar to SOLAR01 dedicated solely for authorization tasks.

The Tx will dived in two frames, left one having hierarchy very similar to SOLAR01.

1. Org Units

2. Master Data

3. Business Scenarios (Module Wise)

The right side will be very similar to what is called a Authorization matrix.( This will having list of tcode as first Colum and All Relevant Roles as first row.)

Clicking on the modules node in BBP will give Authorization Matrix for that module. All u201CTcode Specificu201D Authorizations to be given to a role, will be given module wise using Business Scenarios ( Node).

And Org Unit and Master data level Authorization will be given at their respective nodes. As a result we will achieve the much debated complex data level security.

In Addition the fun part is that existing Security Tx can be giving a single point of access using this program. This can be very much possible as Solman is connected to entire Landscape. E.g. right click on the Listed Tx in Authorization matrix will give a option to take you to su24 for that Tx.

I would divide the functionality of the program(Tx) in three parts.

1. Preparation of template framework .

2. Determine Scale and Scope of Authorization Requirements.

3. Implementation application security.

Preparation of template.

Here solution Manager will have a u201CAuthorization Matrix u201C suggesting different role in accordance with the proposed BPPs specified in SOLAR02. Just like all tcodes are listed according to BBP we will have corresponding Roles.

This will give an idea of what SAP recommends for maintaining different level of security depending on job profiles according to BPP. This can be maintained in one different Transaction all together.

Hence we u201CEnterprise-Wide Role Matrixu201D maintained in solution manager .

As a result Role Implementation Framework Prototype will be standardized. And it will give something to start working on with preliminary data that can be evolved as required.

I know we have accelerator in Road maps in Solman . But if we have tcode for it will serve the purpose better. Read on.

Determine Scale and Scope of Authorization Requirements

This would address the functional part of the discussion. Gathering functional and data level authorization requirements can also be done.

Clicking on the listed Transactions (in Authorization Matrix) against the roles, would take you that screen i.e. made for that specific Tx. Here you can just specify restrictions at functional and data level for that tcode in the given role. Similarly Org Unit and Master Data level Auth can be specified for a given role using u201COrg Unitsu201D And u201CMaster Datau201D nodes.

As a Result Auth requirements are gathered and documented. This data can be used to implement and review security. This can be done by functional Consultants with even knowing the how it is going to be technically implemented.

Solman is a very efficient documenting tool so other feature can also be helpful for the same purpose.

Implemention application security.

Now comes the best part. Regarding how the user roles and authorizations are technically implemented.

The idea here is specifying Authorization for each tcode for each role graphically without seeing object behind. (not all but most of auth)

This will be done using the same program again.Clicking on the listed Transactions (in Authorization Matrix) against the roles, would take you that tcode specific screen which has a kind of replica of actual Tcode screen where you can specify authorization for corresponding Role as follows :

1. Add and remove Tabs of the Tcode graphically.

2. Double clicking on filed will allow you to specify the allowed activity that field.

3. Also it should have provision for specifying organization level and master data level authorization specific to that tcode.

And all such similar auth that can be given at tcode level.

As a Result we maintain the authorization without even knowing which Auth Object are used to implement. Auth Objects needs to be modified automatically for achieving this. As we are specifying Authorization graphically without seeing object behind there are chances that there may be confects and if any conflicts . There should be warring and suggestions for such case. Or can be resolved in classical way.

Finally there will be a generate button that will generate the specific role or also takes you to pfcg for the role.

It will help to remove all ambiguity regarding how the user roles and authorizations are technically implemented.

Hence at least 80% of the Authorization will be implemented using this program. Remaining Intricacies in security will still be implemented using current tools . And it will still require same amount of functional and technical knowledge to finalize and complete all task. So itu2019s not about bypassing the knowledge but about revision of tools.

[Former Member]

Hi,

I have read your post and what I understand is you are suggesting a tool to be developed for the security guys which makes them easy to understand, assign and modify

authorizations on a single screen.

Hey let me take an simple example..

Say a transaction MIGO is assigned to 100 roles in 50 different ways and which is further assigned to 100 different users and on an average an tcode will pull say 10 different authorization objects and each object on an average may have 3 different fields with its field values... you may now have the idea of number of tables being used(probably say 50 tables includes ush, usr agr, tobj etc) Now if you want the entire data to be displayed at front end(oh jesus think if there were 1000 tcodes)....database will be doing this job and will be a big mess with other workprocess getting either hanged up or will be executing this in a loop.

Hey I am not denying the fact that security is difficult task but we need to think of efficiency of the system.

We do have some options in SAP wherein we can can get somewhere closer with only display... by writing your own abap query and pull some data which looks something similar to role to transaction matrix(template)...

Rakesh.

[Former Member]

Hi Hussein,

You obviously have put a lot of thought into this.

Looking back at the subject and ignoring my opinion that SolMan is the spawn of the devil, I can see there being some use in there. In scope t-codes could be assigned to business processes (like they can already - but it's nothing more than that). You could have the facility to group the tx into roles but only used those t-codes which have been defined (and therefore available for testing, prompt for training material etc).

How you define the roles should be completely up to you, those who want to group them into tasks can do that, those who like to build at a higher level can do that. This also generates the role documentation for you & you can identify the critical restrictions at object level. It would be great if you could flag these as not to be overwritten when deriving a role. Following Auke's point, this is very much on the functional side.

On the technical side, personally I would be very cautious about wanting to restrict a certain field for a certain transaction etc, mainly down to the complexity this would involve. In addition letting SAP sort out all the check indicators would lead to many tx being given auths which are not required and could lead to too much access in the background.

Looking to the not too distant future there is also a challenge for security brought about by the increase in automated compliance reporting and user provisioning.

If all user provisioning is done via an automated workflow solution then the technical role build has a lower impact on the user provisioning - as long as it it mapped properly (something many Access Enforcer implementations fail to get right).

Content/technical build quality of roles can be poor as long as it checks out with the SOD tool - despite there being a fair few flaws with this. Of course a technically good implementation will always be better but when paying $1m+ for a suite of GRC tools, it's tempting for IT depts to say we've got the tools so we don't need the knowledge....interesting times ahead I think

[Former Member]

>Say a transaction MIGO is assigned to 100 roles in 50 different ways and which is further assigned to 100 different users and on an average an tcode will pull say 10 different authorization objects and each object on an average may have 3 different fields with its field values... you may now have the idea of number of tables being used(probably say 50 tables includes ush, usr agr, tobj etc) Now if you want the entire data to be displayed at front end(oh jesus think if there were 1000 tcodes)....database will be doing this job and will be a big mess with other workprocess getting either hanged up or will be executing this in a loop.

>Hey I am not denying the fact that security is difficult task but we need to think of efficiency of the system.

Regarding Mess :

Dude This data need not be presended all in one veiw . There can be vaiours abstration level maintained. Thats what I have expplained in my eairlier post. And that too is a vague idea,if SAP works on it , it can do wonders for security implementation.

Regarding Performance :

The Data you are talking about is already there in the system and it is used more foten then any other data, i mean during Roll-in and roll-out.

There ll obiviouslynot be any architectual challenges cause all data we have it in the system. We just ahev to develop a tool to display and change it in a didffrent organized way altogather, But I dont think there can be any performance issuse.

[Former Member]

>Looking back at the subject and ignoring my opinion that SolMan is the spawn of the devil, I can see there being some use in there. In scope t-codes could be assigned to business processes (like they can already - but it's nothing more than that). You could have the facility to group the tx into roles but only used those t-codes which have been defined (and therefore available for testing, prompt for training material etc).

Thats what i posted , BBP is just tobe used as a template to work on. And it wil be ready so no wastage of efforts if we dont use it. Only we need to refine it.

>How you define the roles should be completely up to you, those who want to group them into tasks can do that, those who like to build at a higher level can do that. This also generates the role documentation for you & you can identify the critical restrictions at object level. It would be great if you could flag these as not to be overwritten when deriving a role. Following Auke's point, this is very much on the functional side.

Now thats the tool (program) I have discribed above. May be What I have discripbed can not fully achive what you want but it can be further refined to achive that too.

>On the technical side, personally I would be very cautious about wanting to restrict a certain field for a certain transaction etc, mainly down to the complexity this would involve. In addition letting SAP sort out all the check indicators would lead to many tx being given auths which are not required and could lead to too much access in the background.

Thats too should be done manually IF REQUIRED. Thats about going back to clasic methods to refine and fine tune your security. If we work on this concept may be this too can be achive from this centralized tool as well.

>Looking to the not too distant future there is also a challenge for security brought about by the increase in automated compliance reporting and user provisioning. If all user provisioning is done via an automated workflow solution then the technical role build has a lower impact on the user provisioning - as long as it it mapped properly (something many Access Enforcer implementations fail to get right).

Automated builted roles should be scrutinized manually or can be tested automatedly my a program .

Now this will be a new program where before starting the test you specify the requiremnts such a SOX ,SOD or Org Unit for that perticular role. In this way you achive maintanince of SOX and SOD in SAP system itself.

Testing should generate a list of waring and suggestions to overcome the issues

>Content/technical build quality of roles can be poor as long as it checks out with the SOD tool - despite there being a fair few flaws with this. Of course a technically good implementation will always be better but when paying $1m+ for a suite of GRC tools, it's tempting for IT depts to say we've got the tools so we don't need the knowledge....interesting times ahead I think

Dont you think GRC will be integral part of this security system of which we are thinking about .

I Know most of my arguments may seem silly but I think I have put potrayed my idea. And I still belive there is a lot of scopr of improvment still in existant security tool and mehdology.

Lets see how interesting it get ahead.

[Former Member]

> Thats too should be done manually IF REQUIRED. Thats about going back to clasic methods to refine and fine tune your security. If we work on this concept may be this too can be achive from this centralized tool as well.

And this is my first concern with this type of automation, there is no way that SAP could automatically do this - look at SU24, for obvious reasons, that is not accurate out of the box and needs a fair bit of config to get right. Even then, it pulls through a lot of unnecessary stuff, which if left unchecked causes holes in your implementation. As it is, you should examine every single role (or master role if using derived roles) to ensure that only what is required is in that role. Why not do this at the start to get it right at the start & then use tools to expedite the build.

> Automated builted roles should be scrutinized manually or can be tested automatedly my a program .

> Now this will be a new program where before starting the test you specify the requiremnts such a SOX ,SOD or Org Unit for that perticular role. In this way you achive maintanince of SOX and SOD in SAP system itself.

What you want is something which will do your job for you with minimum effort (an admirable task). It would be (at minimum) 10x more complex than GRC yet with a much smaller market

> Dont you think GRC will be integral part of this security system of which we are thinking about

That's not my point. You can have a really bad security build which will pass all GRC tests. You can have security flaws which will pass all GRC tests (though they are doing some good work on that).

> I Know most of my arguments may seem silly but I think I have put potrayed my idea. And I still belive there is a lot of scopr of improvment still in existant security tool and mehdology.

I don't think your arguments are silly at all, anyone saying otherwise does not really get this whole open forum thing! Creating security with minimum fuss would be nice but like doing automatic config for business processes, the technical challenges are pretty big & I can't think of who would want to invest in them

Cheers

Alex

[Former Member]

>Creating security with minimum fuss would be nice but like doing automatic config for business processes, the technical challenges are pretty big & I can't think of who would want to invest in them

I am glad that gurus suscribe to my thoughts . Also I am sure that after considering increasing landspace size (SAP solutions) and the time required to implement security , SAP will soon realize its importance of improvments in security tools. No sooner then they would want to invest in them.

Cheers !!!!

[WolfgangJanzen]

>

> Using BBPs it could be very easy for system to generate the autorization matrix and related implementation activies.
> SAP did not take it up. 

SAP Business ByDesign is using a new authorization concept called RBAM (role-based access management). The basic idea is: derive "roles" (in general: access control data) from declarative information. That however only works if applications are developed in a model-driven approach and controlled by frameworks. For classic ABAP applications this is not the case.

For classic ABAP applications you can basically only collect tracing information (while testing the software during the validation phase), manually check on the collected data and decide which of that material should be used as basis for role generation. That part is done by SAP developers (for SAP applications), resulting in "SAP roles" which are shipped with the product.

[Former Member]

Problem with SAP standard roles is that they represent only one way to look at the process, while companies mostly have a completely different view on that. One can use them as a startingpoint for own developments

Normal process we apply:

1 Functional consultants describe processes up to Task (transaction) level. Including restrictions seen from a functional view.

2 business consultants (power users) decide by which function what part of the process will be done, = single role design. Business consultants create the Authorization Org Level matrix

3 single roles are build and unit tested. in thsi process most missing authorization objects are found and added to SU24.

4 composite roles are build (representing a function) transported to QAS and unit tested there. As the QAS system contains real data missing authorization values are found and applied, Org level Matrix updated.

5 Integration testing proves that the authorization design works.

So how much need is there for a tool to technically create roles. We have enough tools created in MSACCESS and to build in SECATT and LSWM, But in every implementation we discover that we need a completely different approach so tolls used in previous projects cannot be reused, one should get experienced in working with aforementioned tools so you can build these to the needs of the day!

[WolfgangJanzen]

>

> Problem with SAP standard roles is that they represent only one way to look at the process, while companies mostly have a completely different view on that. One can use them as a startingpoint for own developments 

Yes, I agree - but that's even stated in the documentation: you shall derive your own roles from the ones delivered by SAP. That's kind of part of the customizing. Reason: every organization is different and has different security requirements.

> ... but in every implementation we discover that we need a completely different approach so tools used in previous projects cannot be reused ...

That's an interesting insight. Do others share the same opinion?

[Former Member]

>

> >

> > ... but in every implementation we discover that we need a completely different approach so tools used in previous projects cannot be reused ...
> 
> That's an interesting insight. Do others share the same opinion?

I can see where Auke is coming from. For me there are a few core tools which can expedite the build in 99% of cases, tasks I like to automate if possible:

Derived Role Creation

Org Level Population

Composite Role (if required) creation

User Creation/Role Mapping

Bespoke reporting

Role design on the other hand is much, much harder as by it's nature a tool will encourage you to build in a certain way - like Securinfo & value roles for example

[Former Member]

> That's an interesting insight. Do others share the same opinion?

I cannot say that I share exactly the same opinion, but Auke does have good points. Hussain as well.

My personal take on this is that not only SAP's standard roles, but also the delivered SU22 (and then SU24 settings) are not always complete or maintained and may differ from the implementation requirements. Of course that is what SU24 is all about... creating an implementation specific tool using standard tools (and coding) to fit the choice of business process design.

The choice of transaction chosen increases in importance though when making these decisions to copy or develop own implementations of the delivered intention of a transaction (be it PFCG, MSACCESS or other external UI / scripting tools - which also bare other security risks sometimes...). I would class the choice of tcode as the single most significant point of failure in the security implementations which I have seen. A very close second for points of failure are the programs from the Z* and Y* range. Which also agreed with several of Auke's comments that the functional folks are not knowledgable enough about security or themselves are using some copy&pasted template which worked last time (or at least, it worked in the unit tests...).

The tools used for it should ideally be as irrelevant as possible, if the intention and abilities of the transaction (or RFC or service) are known. In that sense, I think a worth while investment from the SAP side is to educate developers to maintain SU22 correctly; and from the customer / partner side to not only change SU24 but also report missing default data to SAP or opinions on the scenarios for the use of the functionality, and of course also train functional folks and developers.

Of course, that is only the ABAP side of the coin, with main focus on the transactional systems.

My 2 cents,

Julius

[Former Member]

I hope this gets attention of the right person

So next release we can work with ease on security.

[Former Member]

Dose any of these difficulties are answered in GRC.

I am waiting to work on GRC but till far did not get any opportunity.

I believe GRC must have addressed some of the issues discussed above.

[Former Member]

The Access Controls toolset contains ERM which is a frontend to PFCG. It does some nifty stuff with org data sets & forcing naming conventions but given the choice I will not use it until it is working yet. The early versions were a farce and the newer version is only marginally better. It still won't do your job for you

[Former Member]

It won't do F4 for you. Sometimes PFCG in a development system doesn't either..