topic Re: capturing auth check in background for functional testing in Application Development and Automation Discussions

capturing auth check in background for functional testing

Former Member — Wed, 24 Nov 2010 16:59:52 GMT

Hi All ,

We want to build a program which monitor all the authorization objects checks for a tester and then prepares a report with all these authorization This report will then be used by a security consultant to build a role or update existing authorizations .

I know ST01 does help us on this but we wanted to add more features to it by adding change request number number for tracebility .

Is there any way to multiple session for trace .this is because we will have multiple tester doing testing at same time . and currently i see that either we can switch trace for one user or to all users in the system .

Any other ideas to do this are also welcomed .

Re: capturing auth check in background for functional testing

Former Member — Wed, 24 Nov 2010 17:15:45 GMT

Hi Rakesh,

I feel you are making the process too complex. A custom program to analyze the auth objects in another custom program, and by adding the CR #s using another program.... huh.. too many programs

This is pretty simple. Any custom program should have some level of authorization restriction through an AUTHORITY CHECK statement, or S_TABU_DIS (if the program retrieves data from tables.) You can easily search for them using SE93 (incase of AUTHORITY CHECK), or TDDAT (table authorization group) table. Make use of them and don't recommend using thousands of custom programs and make yours and the auditors life miserable.

If you still need a program and don't think that it hurts the system performance, and makes the process complex, you have to switch the trace at the user level in ST01.

Regards,

Raghu

Re: capturing auth check in background for functional testing

Former Member — Wed, 24 Nov 2010 18:08:19 GMT

Hi Raghu ,

Thanks for your reply . I think i made you confused . Let me try to explain again in simple way ,

Instead of having Fuctional team coming back and forth for all the security testing we want to use a custom program which will run in background to capure all the auth check that were executed by the tester . The report will then be sent to security to review and update the role .

My question is if there is any way we can do multiple users trace at same time . (I know we can do one user or full system trace but looking for multiple user option )

Edited by: Rakesh Navandar on Nov 24, 2010 7:12 PM

Re: capturing auth check in background for functional testing

Former Member — Wed, 24 Nov 2010 18:41:37 GMT

Why should the funtional guy go" back & forth '? the AbAPer needs to know which objects are beign checked ! Or involve the security team memeber in the development.

Re: capturing auth check in background for functional testing

mvoros — Wed, 24 Nov 2010 19:47:24 GMT

Hi,

as far as I know you can have only one trace for each application server. But you can run your tests with different usernames and then split trace data using username. But I don't understand why you want to generate these reports. You should try to use only values from SU24 during build of your roles. The consultants can just put all relevant tcodes to role, fill missing values and then run your program if it's enough or something is still missing (SU24 is not perfect).

Cheers

Re: capturing auth check in background for functional testing

Former Member — Wed, 24 Nov 2010 21:05:09 GMT

Hi GG,

I agree with you. Working closely together with the developers is best for them and for you and the security aspects of the development work, but that only applies to custom development.

For config of SAP standard functionality you need a functional guru to work with - again preferably a good one who appreciates security aspects.

Testing is a different scenario and still will produce changes required which were previously unknown.

@ all:

An idea I have (possibly for a community project?):

There already is an SDN blog on how to trace users and extract more usefull information from the trace, and I hope we will see it in the standard soon. See [Frank Buchholz's "Show ST01 authorization trace"|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16729] [original link is broken] [original link is broken] [original link is broken];

Now with that as data source, we could assign a personal "delta role" to each (set of) tester(s) and have a job monitoring the trace every minute or when the user triggers an event (would be better).

The step program reads the trace information into the program for all sy-subrc NE 0 and then filters out a "black list" of known red-herrings, such as:

S_TCODE = values which don't exist in TSTC are typing errors.
S_ALV_LAYO = ALV reports open to change the layout.
S_CTS_ADMI = TABL provoked by returning to the menu or CALL SCREEN 100.
S_TRANSLAT = actvt '02' provoked by messages.
S_DOKU_AUT = ' ' provoked by views.
S_DEVELOP = DEBUG '03' provoked by Short Dumps and report writer queries to make 
*               the DEBUG button invisible.
S_USER_GRP = actvt '05' provoked by many vendor and customer transaction in logistics 
*                where the old SU05 "internet user" was given the option to 
*                change their "internet password".
S_PROJECT = ' ' provoked by the F4 search help on many fields. 
S_BTCH_ADM and S_BTCH_NAM = show up as failover for S_BTCH_JOB and set screen 
*                variables in SM37 / SM36

Additionally, we could collect a program / tcode context list with reason codes to add for other well known application specific red-herrings. Org. levels will be tricky, but can be done.

Other "critical" authorizations which are known will be easy to add to a negative "black" list. Just ask your auditors for them...

Then, based on what is left over... we automatically re-generate the profile of the already assigned delta role so that the user can carry on testing.

Another feature option would be to additionally transfer all the left over data with the tcode contexts to a flat file in the format of the SU22 "original data" upload, and then use SU25 back in DEV to upgrade the roles from the testing results instead of manually transfering the the delta role to the real one.

I built a very similar solution for a customer once for K_REPO_CCA but they ended up not using it because they converted to K_CCA.

I think the trick will be to collect the DB for the "blacklist" (to be perfect, it should be release dependent... but community projects are good for such data.

Also the calls for the generation are not released functions and very tricky to use so they might change or easily go wrong in local addaptations (variables in screens are global!). As a community effort we might be able to persuade SAP to provide interface stability though and add warnings about being attacked by devils if some includes are touched?

I would be very happy to contribute, but don't want to end up doing everything (like some other security wiki requests have...).

Anyone else interested in working on this?

Cheers,

Julius

Edited by: Julius Bussche on Nov 24, 2010 10:12 PM

Re: capturing auth check in background for functional testing

Former Member — Thu, 25 Nov 2010 10:06:32 GMT

Hi Julius,

Awesome! I like the approach. Let me know what other contributions are required? I am ready to take up tasks to get a more better and better features. Let me know.

Rgds,

Raghu

Re: capturing auth check in background for functional testing

Former Member — Fri, 26 Nov 2010 19:16:33 GMT

Hi Raghu,

I am first checking with SAP whether they have something similar in the pipeline or concerns (I have one) and will get back to you.

Cheers,

Julius

Re: capturing auth check in background for functional testing

Former Member — Mon, 29 Nov 2010 12:19:15 GMT


> Hi Raghu,
> 
> I am first checking with SAP whether they have something similar in the pipeline or concerns (I have one) and will get back to you.
> 
> Cheers,
> Julius

Just the one concern?

I'm also happy to contribute to this so if there is anything I can do, fire away.

Re: capturing auth check in background for functional testing

Former Member — Mon, 29 Nov 2010 14:16:14 GMT

is that program not executable in foreground?

if yes, then debug and put breakpoint on 'authority-check' keyword.

Re: capturing auth check in background for functional testing

Former Member — Mon, 29 Nov 2010 22:06:13 GMT

Hi Julius ,

Thanks for you reply . I am working on this solution with a bit different approach .

What i was thinking was to get all the auth objects that were run by tester and then check with the composite role on what objects are missing The report will then be sent to security consultant . Security consultant will then mark the objects as Include/Exclude . The program will then be enhanced to modify the role to add all the objects that were marked as include . (Still i need to work on this design )

Currently i am struck with the problem on how to state trace for multiple users only . I dont want to start the trace for all the user as we will end up creating a large trace file and then work on regular clean up. i will not be able to use single user trace as lot of tester will be testing at a same time . Can anyone share opinion on this .

Re: capturing auth check in background for functional testing

mvoros — Mon, 29 Nov 2010 22:53:50 GMT

Hi Rakesh,


> What i was thinking was to get all the auth objects that were run by tester and then check with the composite role on what objects are missing  The report will then be sent to security consultant . Security consultant will then mark the objects as  Include/Exclude . The  program will then be enhanced to modify the role to add all the objects that were marked as include . (Still i need to work on this design )

I don't think that this is feasible approach. Generally, you should try to avoid adding manual objects to roles. You should always try to use SU24 entries. In this case you want to identify missing objects which is OK but then add manually all missing objects into role which is wrong. If you want to do it properly, then you need to figure which transaction should be added to role or which transaction is missing that object in SU24. I don't think it's possible to do automate this step.

Cheers

Re: capturing auth check in background for functional testing

Former Member — Tue, 30 Nov 2010 18:09:42 GMT

Hi Julius ,

Did you get any reply from SAP if there is anything like this in pipeline .

Thanks Rakesh .

Re: capturing auth check in background for functional testing

Former Member — Tue, 30 Nov 2010 18:14:57 GMT

Hi Martin

" In this case you want to identify missing objects which is OK but then add manually all missing objects into role which is wrong. "

I agree with you that we should not add objects manually to the role . I am still working on the design and feasibility and also how it suits our landscape .

All ,

Still looking for option on tracing multiple user(Not ALL) at a time .

Thanks

Rakesh

Edited by: Rakesh Navandar on Nov 30, 2010 7:16 PM

Edited by: Rakesh Navandar on Nov 30, 2010 7:17 PM

Re: capturing auth check in background for functional testing

Former Member — Tue, 30 Nov 2010 18:28:34 GMT

It will take a little while, so don't stop your project...

@ Martin wrote:

If you want to do it properly, then you need to figure which transaction should be added to role or which transaction is missing that object in SU24. I don't think it's possible to do automate this step.

This data (transaction context, source code location, reason codes) is available in the ST01 trace file and (optionally) as you know in table USOB_AUTHVALTRC as well.

If there were a "black list" and "white list" of these contexts for objects which are known to be not allowed or generally okay (such as "base check functions) then the manual steps of maintaining SU24 could be automated to an extent (via SU25) and more importantly --> for testing purposes the event of the failed auth check can add the authorization values to the user's delta role automatically so that they can carry on testing.

This is a much better approach IMHO than SAP_ALL with trace on or relying on transaction SU53 (may your armpits become infested with the flees of a thousand camels...) information to automatically build roles or find missing auths.

The two main hurdles I see are gathering a ruleset for the blacklisting and whitelisting (which I think an SDN wiki would be a cool source for), and, a stable API for the role generation (for this we need help from SAP because there isn't one).

Cheers,

Julius

Re: capturing auth check in background for functional testing

Former Member — Tue, 30 Nov 2010 19:17:23 GMT

Hi Julius ,

Thanks for your guidence .

Would it be recommended to put ST01 trace on for such solution .What kind of approach you followed previously .

Also how was the load on the system and was there any effect on performance .

Appreciate you help !

Thanks

Rakesh

Re: capturing auth check in background for functional testing

Former Member — Tue, 30 Nov 2010 19:36:44 GMT

With a limited amount of activity going on, yes you can use that - but there will be performance impacts from ST01 on very busy large numbers of users.

A better option would be to use the solution described in [SAP Note 543164|https://service.sap.com/sap/support/notes/543164] . I have used this before and was very happy. However it will only propose "original data" values to you where the code reached the check, with the intention of adding them to SU24 back in DEV as a manual process. Some well built roles with good functional gurus, then is normally not necessary.

It also explains some of the nonsense in SU22 when "the rules" are not understood or adhered to... --> see Frank Buchholz's answer to question # 1 in

For larger developments with lots of testing going on in authorization areas where none of the gurus has gone before and no captain's logbook was left behind to read either... it is the Rolls-Royce of what is currently available.

Cheers,

Julius

Re: capturing auth check in background for functional testing

Former Member — Fri, 07 Jan 2011 21:55:01 GMT

The two main hurdles I see are gathering a ruleset for the blacklisting and whitelisting (which I think an SDN wiki would be a cool source for), and, a stable API for the role generation (for this we need help from SAP because there isn't one).

I have been playing around a lot with this and managed to solve these problems and am almost finished with the coding.

Using shadow tables for black, white and grey lists from the usage of the system and failed auth checks, it is possible to give these messages, user behaviour, sy-tcode contexts, source code locations, return codes and reason codes some application logic life to generate roles based on the events. I am even adding a "check SAP Notes" feature which will look context specifically from the results for authorization relevant SAP notes as "hints" to navigate into when reading the log.

A prototyp example to illustrate the automation when no user interaction is required nor possible --> Create a basic role for a SYSTEM RFC user (see SAP note 460089) and then let the interfaces run for a while. When you get back from your coffee break, pub lunch or vacation... the role based on what it actually used (minimum rights principle) is finished.

Same goes for end users given the task of testing what they need or their existing roles after upgrades or generating "delta roles" which contain only the "delta authorizations" for emergencies.

Cool heh?

If anyone would like to be a "beta tester" then let me know. I would need to verify the data I have in the shadow tables and that it's artificial intelligence to collect the generation rules in the tables works for various obscure scenarios.

RESPAREA in controlling I have covered already (if that means anything to you...). Asset Accounting, HR and Industry Solutions are going to be a tough nut to crack. For the moment I black-listed them...

Cheers,

Julius

Re: capturing auth check in background for functional testing

Former Member — Sat, 08 Jan 2011 00:03:31 GMT

This goes way over my head to be perfectly honest....

I can see that the thread has investigated some interesting options for delta check etc but are we getting way ahead of ourselves here? Are we going back to a profile all trace and filling in the gaps?

We know the user will run F110 (say) but then go off on a tangent and bring in multiple objects based on their understanding of the proess rather than the best practice.

Sorry to be a kill-joy but I think we need to keep it simple but maybe this is more advanced than I am used to?

Kind regards

David

Edited by: David Berry on Jan 8, 2011 12:05 AM

Re: capturing auth check in background for functional testing

Former Member — Sat, 08 Jan 2011 00:55:13 GMT

Yes, there is a "**** in **** out" aspect to it, that is always omnipresent... but with an application logic between the result (and contexts, and blacklists, etc) and the generation you can filter out much of the nonsense returned from the runtime environment.

The beauty of OO programming is that you can TRY and CATCH exceptions at all layers of the application (UI, processing logic, logical unit of work in "helper classes") and make the thing articifically intelligent depending on the layer the interaction is comming from.

User input is often not intelligent and should not assumed to be so, until validated (as a little example...).

As a sceptic, you make a perfect beta-tester. Upgrade to paranoid control-freak and this is exactly what you are looking for plus the system still works without short-dumps...

Sorry to be a kill-joy but I think we need to keep it simple

That is just User Interface (UI) programming. Important and should not be faked for what is really happening under the bonnet, but it is possible to make a UI for such a tool very intuitive and simple, even although the business logic in the application is complex and in this case has the ability to adapt itself to it's use. The more it is used, the cleverer it gets to build roles.

Artificial intelligence in ABAP (in a light-weight sense, without blowing up the planet or anything like that...

Anyway, I thought it was a cool idea and am puting some effort into it without it generating **** authorization values or "guess work" (very common point of security failure).

Cheers,

Julius