Who creates the authorization objects

[Former Member]

I have recently come across a situation where the ABAP custom development team wants the Authorization Support team to create authorization Objects

(Transactions SU20, SU21) for them. In my experience i have never come across such a situation where without understanding the business logic of the custom program, an authorization personnel creates an object for the developers to use in its program.

What is your view on this? Should this activity be performed by the Authorization Support team or the Development team.

Apparently the development team doesn't know how to play around authorizations (Authority-Check)

Is it normal?

(Dear Moderator: I have delibrately posted this question in this forum to know the developers view on this)

Regards, Amol

[Former Member]

Hi Amol,

It depends on your organisation's "Who does what". Mostly Security / Basis team does this activity but in some company even ABAPers does. Since you are part of a dedicated Authorization team i think you should not be leaving this to the ABAP team.

Sit with your ABAP team and try to get the requirement on the Authorization object. I do not think you should need the entire business process apart from the authorization part.

Hope you can help your ABAP team with the authorisation objects they want.

Regards,

Karthik D

[ThomasZloch]

Should be a joint effort. If the development team has a task that involves authorization checks, then it should collaborate with the authorizations/security team on how to implement these properly, as supposedly there is a detailed SAP authorization concept in place, that should not be undermined by one-sided activity.

Creation of new authorization objects (and corresponding roles) can be required e.g. for totally new applications. Whenever possible however, standard SAP authorization objects should be used. For example, a custom program that posts FI documents should check the standard F_BKPF* objects.

So in your case, I would question the need for new objects, ask for an explanation, and align with your overall security concept.

Thomas

[Former Member]

I agree completely with Thomas. Security solutions can't be built by either developers or the authorisations team in isolation as typically neither side understands the whole context. I would expect the developers to be creating the custom auth objects, but their structure (fields available) and purpose (when and how the authority-check statements are called) must be designed in conjunction with both the functional/business consultants and with whoever is responsible for your governance. The correct working of the auth objects should be included in any testing, of course, and again the construction of those tests will be a joint effort, to ensure all of the necessary scenarios are included.

Steve.

[Former Member]

You might want to talk to the internal auditors as well to get their ideas on this. You might run into security issues if developers create, assign and then check authorizations.

I think developers should check authorizations if necessary, but the authorization people should assign them based on the business requirements.

Rob

[Former Member]

Absolutely. I had internal audit in mind when I talked about "whoever is responsible for governance". I guess not everyone has an internal audit team, but also sometimes audit feel their role is to monitor and report rather than to advise and interfere. I understand their point of view, although it is sometimes frustrating!

If you have an audit team, and they'll talk to you, you should definitely take their advice!

[Former Member]

Well a couple of chain mails and the outcome is the internal audit/SOX team has got no idea about it. They are completely clueless about what authorization objects are.

But the general understanding that i get from this forum is that, it should be a joint effort.

Amol

[matt]

If it's left to the ABAP team - you get too many objects created. If it's left to the auth team, then the objects may not meet the actual requirements. So, yes - joint effort!

[Former Member]

That doesn't surprise me. They don't need to know any great detail, but understanding the principles will help any discussion go smoothly. I've run an "intro to SAP authorisations" course for our audit team. They've appreciated it and it avoids loks of frustrated "but that's not how it works" discussions.

[Former Member]

Hi Amol

I've gone through the process of getting a company to be SOX compliant and found that the approach the company followed was a bit tedious but necessary. They got the business to let them know exactly what Z/Y transactions who uses. A lot of Custom/Z Reports don't need additional authorization checks, the standard SAP checks where enough, in other words if the transaction was not assigned to that specific users role then he/she could not execute the transaction, keeping in mind that SA38 and SE38 was also removed from their authorization list. In the end when it comes to developing additional authorization checks into a program the Business and functional consultants have to discuss which transactions at whichever point falls under which authorization objects. If it is left to the developers to do, what happens when new developers come into the company, they don't know what custom objects are available for which ever department and what happens when they just decide not to add additional authorization checks at all?
In conclusion Business, functional, security/basis and the senior developers has to be involved with the decisions and implementations of the authorization objects Standard or Custom.

Regards

Vic

[former_member209920]

It should always be 'Joint Effort'.

And SAP implementation cannot be performed by one.. be it ABAP Consultant(s) or Functional Consultant(s).IT is Always TEAM EFFORT which gives results.

About authorization objects, they can effectively created only with the joint effort of ABAP, BASIS, concerned module Functional and of course Authorization Team (or Security Team) as well.