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: 

Adding authorisation object to custom reports

Former Member
0 Kudos

Hi,

I'm a little new to authorisations (I'm a developer) so I might be asking a really basic question (although I have searched the forum and not found the answer).

I have several custom reports which I've been asked to add an authorisation check into, to check company code and sales org. These reports are all in different roles so don't have an authorisation object in common.

Is it normal practise to create a custom authorisation object say ZFI_BUKRS and ZSD_VKORG, add this into the program code and add them to all FI and SD roles? Or is there an easier way?

Thanks,

Gill

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

You could create custom auth objects or use standard objects if you can find ones that are suitable. This really should be documented in the security strategy or supporting documentation.

In this case I would refer the question to your security team so they can tell you what they have used before and what they would prefer.

Personally I like to use standard auth objects where possible and then use custom to address gaps or different functionality.

6 REPLIES 6

Former Member
0 Kudos

Hi,

You could create custom auth objects or use standard objects if you can find ones that are suitable. This really should be documented in the security strategy or supporting documentation.

In this case I would refer the question to your security team so they can tell you what they have used before and what they would prefer.

Personally I like to use standard auth objects where possible and then use custom to address gaps or different functionality.

0 Kudos

Thanks Alex, it was the security team (or Jane as she's known) who asked me to look into this. We've not added additional securities to our custom programs before and it's been highlighted as we're going-live with a new sales org and company code so we need to restrict the data in some of the reports.

I've been investigating SU24 as this might be useful going forwards to make sure that when a custom tcode is added to a new role it pulls in the correct objects. But I'm still leaning towards the custom object route.

0 Kudos

Hi Gill,

I hope I don't sound out of place here, but it is your security team's job to identify this kind of stuff and do most of it for you.

I would expect their responsibility to cover:

- ID requirement for restriction in a report

- Define auth objects that need to be used & appropriate logic (along with func team)

- Build auth object in SU21

- Maintain SU24 with object and appropriate values

Basically, they should be telling you what they need & what auth objects to use. Being a developer, your skills lie in making the code meet their requirement, I think it is unfair that they get you to work on things that they should be on top of.

0 Kudos

Thanks for your input Alex, but that's not a great help to me. The lady who does the authorisations has never had to add custom objects to programs before so wanted my input, I have done authorisations before but never in this much detail. I'm trying to help her out as much as possible as she's overloaded with work as it is. We're a small team so there's a lot of cross over on responsibilities.

I think I'm going to go with my first thought and create 2 custom authorisation objects, add them to the tcodes in SU24, add them to all roles and to the program codes.

0 Kudos

Good luck with it Gill. You may already be doing it, if you aren't I would strongly recommend that you include Activity (ACTVT) as one of the fields in your auth object. That way you can use it in custom reports (auth check on activity 03) and also on any programs that require create (activity 01) or change (activity 02) access. This flexibility could save you lots of effort in the future. Ideally, all custom transactions (reporting or update) should have relevant auth checks in place in the underlying program. When defining your custom auth objects, you can do a little bit of extra work now to ensure that they can be used for other purposes should there be a future requirement.

0 Kudos

Thanks Alex, good tip on activity, I will add that in thanks.