Metrics for role design

[mvoros]

Hi experts,

I just saw a nice presentation about metrics for code. To summarize the main idea, you can extract some metrics from code and use it for improving quality. For example you can calculate toxicity for each class using various criteria. You add one point if class has a method that is longer than 30 lines. Two points if method is longer than 60 lines and so on. You can sort all your classes by calculated toxicity. This list can be used for identifying the most problematic parts of your code. If you plot your data in a bar chart you can also derive an overall quality of code. If there are too many classes with high toxicity then quality seems to be low. But if toxicity drops pretty quickly than it seems to be much better. This approach is especially useful if you start working with new code base. You can not easily see quality from source code.

So I would like to do similar thing but for roles. I would like to develop a simple report that would give me an overview for selected roles. I think that it will be very useful when you start working with a new system/customer. I am not saying that there is a magic formula which can be used to determine if role structure is good or bad. But I think that these metrics can give you a quick overview. For example most of the roles are really big and have massive menu structure. Another example can be that there is too many roles with too many manually added authorization objects.

I already wrote a simple ABAP report and I am happy to share it with community. I spent only 30mins so it's still dead simple. What it does right now is that you can restrict selection of roles. For each selected role it calculates the following values: toxicity, number of auth. objects, number of manual auth. objects and number of menu items. Same report can be produced using SE16 and some excel magic.

I believe that criteria for toxicity are really subjective and specific for each system. I would say that adding one point to toxicity for each manually added authorization object is a good idea but it's really hard to identify what's the optimal number of menu items. I guess it's even harder for number of authorization objects.

I would like to ask if you can think about any other metrics that could be useful for overall assessment of roles in the system. Any tips for calculating toxicity of role from experience will be appreciated. Any comments/ideas are welcome.

Thanks,

Martin

[Former Member]

Hi Martin

Sounds good!

Would a check on the number of S_* objects and then their update access be of any use if found in business roles? Also, a check for any fields containing org levels which have been maintained instead of via the org level input?

Regards

David

[Former Member]

Hi Guys,

Nice idea! There is a neat looking product developed by one of our friendly mods which does similar (I think).

These will have different ability to be delivered but some quick thoughts are:

Number of changed auths

Adherence to naming convention

Use of wildcards (hugely subjective though!)

Org values hard coded

Harder to achieve but quite useful - commonality between roles (excluding child roles). I keep meaning to demo some (non-SAP) software which could help with this.

[Former Member]

Nice initiative Martin!

I have put a little fleet of them together into a "Role Profiler" tool which checks and compares roles for quality aspects, those needing a merge (or nudge.. , stuck in a transport sequence, calculating SU24 optimization of proposals, etc.

The quality aspects are indeed very subjective but what you can do is to "antidote" the "toxic" to some extent. For example: a large role with a menu assigned to a set of users as the only role in addition to a "mitigated" common functions role is a best practice, if it can be achieved and still meet the requirements. (making mitigation possible is very usefull - such as mitigate completely, or mitigate until next change, etc).

Now make it 2 such roles assigned to the same users with slightly similar tcodes in slightly similar menu structures with menu redundancy turned off and the users of these roles have many entries in favourites which are slightly similar to the role menus and those manual S_TCODE values match the favourites but only slightly, then a different interpretation of the role quality should be concluded (or indicated by the reports).

The cool thing about such analysis tools is that they let you quickly detect someone who is "breaking" your roles, as often this goes unnoticed. There is also a BADI in the STMS via which you can scan TP requests for the ACGR entries when releasing a the task.

Cheers,

Julius

BTW: AFAIK the top end of the benchmark is 16 million SU01 users all of which have roles only containing "standard" authorizations built via 50 webservices in the menus, which was designed by one of the other mods...

The worst I have seen is 7000 roles for 350 users with "fake" transactions in the menus and 1 role per real tcode so that SoD checks could be bypassed while building the roles, which was designed by one of the accidents out there... ;-(

Edited by: Julius Bussche on Aug 31, 2011 4:57 PM

Spelling mistake corrected.

[mvoros]

Thanks guys, I knew that I will get some useful feedback here.

David:

S_* objects: I added this one but not sure what relation is between number of S_* and toxicity of role. I leave it from calculation for now but definitely useful metric.

Modified org. fields - really good one. I added it to my report. I completely forgot the org. level fields.

Alex:

Number of changed auths - I added this on object level. So currently there is not difference between object with one or two modified fields.

Adherence to naming convention - good one but that is really specific for a system. I leave it for now.

Use of wildcards - I was thinking about this one but sometimes wildcard is OK. I added it to report but it does not affect toxicity.

Org values hard coded - fixed.

Julius:

thanks for comments. I want to keep it very simple. Altogether I spent like 2 hours on this report (I don't count time spent by you guys and it's dead simple but I already see benefits. The only bad thing is ALV sucks and it does not have any chart options. I just run it for custom roles and I immediately could see which roles are "funky". It's also fun to run it for delivered SAP roles. Currently, I count toxicity as one point for modification of org. value, modification of object value and manual auth. object. Role SAP_SCM_INTEGRATION_DIMP seems to be pretty toxic (there might be a good reason for it).

As I said I am happy to share it with anybody and actually, I would like to hear some numbers after running a report. I don't think that the code exchange is not a good spot for this report at this time. So any ideas how to share it? Maybe just wiki page somewhere here on SDN.

Cheers

[arpan_paik]

Manually added S_TCODE. For that one standard FM/program is available (I forgot the name, but I guess you know that)

However as this is about toxicity of a role so would say below things as well.

1. As mentioned by Julius SU24 vs role authorization. For any existing role a simulation should be performed whether any new object is pulled or not. If yes then the responsible should be heavily fined !!!

Edited : On a other thought, SAP should puull a check for this simulation while we click on generate profile and a error should prevent to generate the role. Only save. then again enter the role to clear the mess and generate properly.

2. The purpose of building role is for business/admin only. I leave admin part (though important). So if we can validate the business need vs actual role that will be a good metrics to measure toxicity of a role. But how to achieve that? I gave a many fancy thought to that but end up confused. If we could have a good documentation for business process then it may turn bit easier.

3. Similarity of multiple roles. Ohh I hate this. There are many who believe to provide access by any means and most easy way to create a new role to provide access as per SU53 (trust me, they don't know ST01). And this is common when business decision maker is non-technical background.

Regards,

Arpan Paik

Edited by: P Arpan on Sep 1, 2011 5:09 PM

[Former Member]

Yes, I also tried to keep it simple but the nature of the beast is complex...

Keep the UI simple and add a configuration option for the report(s) where the subjectivity should not be hardcoded. That is what we did based on first feedback - as you must consider that much the same with coders, the security admins are not used to being monitored by such a tool but would like to use it themselves. Can be a hot potatoe to hardcode the subjectivity...

The only bad thing is ALV sucks and it does not have any chart options

There is a graphics option in ALV but not user friendly. Actually appears to be more concept than code (or I dont get it).

The IGS (Internet Graphics Server) has some cool options though for graphics which you can pass your ALV data to from the results.

Cheers,

Julius

[mvoros]

Arpan: thanks for feed back. For now I want to keep it simple. Hence no role comparison.

Julius: the issue is that I want to keep it also simple for deployment. At least this version of report. Hence toxicity is calcualted in one routine and anybody can change it to anything more meaningful for them. ALV has some graphics capabilities but it sucks. It can be overcome by using Crystal Report for ALV (7.02 required).

Anyway, once again thanks all for feedback. As I promised I uploaded this report to SDN and it can be found on this [wiki page|http://wiki.sdn.sap.com/wiki/display/Security/QAMetricsforRoleDesign]. I really would like to hear some numbers from other systems

Cheers

[Former Member]

Hi Martin,

The program is giving errors. There is some problem with the below lines:

 DATA: lt_fc TYPE slis_t_fieldcat_alv,
        ls_fc TYPE slis_fieldcat_alv.

Is it working fine for you?

Regards,

Raghu

[Former Member]

These ALV field catalog classes came with release 7.00, so you are probably on a lower release?

Cheers,

Julius

[Former Member]

Hi Julius,

I am on ECC 6.0 with Release 700 Level 0024. (For both ABA ad BASIS).

BTW, What is the alternative for those who are on older versions?

Regards,

Raghu

[Former Member]

Perhaps you should rather add this as a comment to the wiki?

If you run a syntax check it should tell you what the problem is though? (I have not copied the report yet, but assumed your problem is that the type does not exist, or does it say something about formal parameters?)

Cheers,

Julius

[Former Member]

Hi Julius,

I've posted my comment there..Here is the error:

Syntax Error in program, Line 36 and 37

Type "SLIS_T_FIELDCAT_ALV" is unknown

Field "SLIS_T_FIELDCAT_ALV" is unknown. It is neither in one of the specified tables nor defined by a "DATA" statement.

Regards,

Raghu

[Former Member]

Looks like a typo. Remove the "_T" from the type and reactivate it.

Martin is however using very high releases (based on some of his posts) so he might ask you to change it back and upgrade to 7.30

Cheers,

Julius

[Former Member]

Hi Julius,

Still have the error:

Type "SLIS_FIELDCAT_ALV" is unknown

Yes, he is. Lets see if he has a solution for people like me who are on lower versions

Regards,

Raghu

[Former Member]

Ok...

Change it back to "_T" and remove the blank spaces before the DATA declaration statement such that activate code is left alligned (or hit "pretty painter" button to allign the copy&pasted code from the wiki correctly).

Or remove the semi-colon ":" after DATA - I think that should also work as it is only declared once.

Cheers,

Julius

Edited by: Julius Bussche on Sep 9, 2011 11:01 PM

[mvoros]

Hi Raghu,

first of all,thanks for testing. The system used for development was 7.02 (I would like to play with 7.3). Those types are pretty old, so it should work with your release. Could you try to add the following line

TYPES: <slis>.
TBLES: agr_define. "This one is already there

or

TYPE-POOLS: slis.
TBLES: agr_define. "This one is already there

I knew that it's a bad idea to release code. You have to support it

Cheers

Added another option.

[Former Member]

Martin,

I've tried your solution with no luck:

If I give TYPE-POOLS: slis, I have the below error in Row 42:

"LT_FC" is not an internal table "OCCURS n" specification is missing.

If I replace it with "TYPES: <slis>.", I am experiencing the below error in Row 37:

"<SLIS>-" expected, not "SLIS_"

I've replaced "SLIS_" with "<SLIS>-", which has popped up a new error:

The type "<SLIS>" has no structure and therefore no component called "FIELDCAT_ALV".

So.. some thing to play with lines 37 & 38

I hope your program should have a backward compatibility too should work on 4.6 even lol

Regards,

Raghu

[mvoros]

Hi,

if you used that first option was lt_fc defined as

DATA: lt_fc TYPE slis_t_fieldcat_alv,

Because that error means that you are trying to add line to variable which is not table. The type slis_t_fieldcat_alv corresponds to internal table.

It should work on 4.6C but I don't have access at this moment so I can't check it.

Cheers

[Former Member]

still no luck..

[Former Member]

TYPE-POOLS slis. (also without semi-colon like the DATA statement).

TBLES with "A" and might make sense to include sscrfields and an INCLUDE : <list>.

I would suggest waiting for Martin to confirm that the wiki code is correct and formatting can be copies 1:1 into the ABAP editor.

Cheers,

Julius

[Former Member]

It copies and pastes fine into my sandbox which is a pretty recent flavour of 7.something (I don't have it to hand).

There is a syntax warning if you run the check but it activates & executes fine.

[Former Member]

Its not working for me and throws an ABAP dump when executed.

[Former Member]

Just add the type-pool after the tables declaration:

TYPE-POOLS slis.

Then it activates and works without syntax errors.

Unfortunately the wiki has some "lock" on it and I could not edit it (saving had no effect - probably an IE 9 allergy against SCN wiki ;-). Perhaps Martin can add it?

Cheers,

Julius

ps: Tcode SLIN also returns a warning on a pseudo comment which does not exist in 7.00.

[mvoros]

Hi guys,

yes, I copied whole program from wiki into system and it works without any issue. The problem is that I have access only to 7.02 systems. My guess is that newer version somehow automatically includes some basic types. In older releases the programmer must explicitly include type pool. This can be done using command TYPE-POOLS slis.

7.02 syntax checks is more verbose and it displays more warnings than previous versions. As far as I remember the warning message for my report is about that select statement selects less fields than number of fields in internal table. In this case it's OK to ignore this one.

Julius: not sure why you can't modify that wiki but I added that missing line there.

Cheers

[Former Member]

Hi Martin

Back to the original post.

Would a check for the 5-6 objects relating to cost centres in derived roles be possible please?

I hate derived...

edit - unless there's a client out there hiring who likes derived

only kidding - even then I still hate the damned things - edit

cheers

David

Edited by: David Berry on Sep 12, 2011 9:07 PM

[Former Member]

I guess it depends on whether KOSTL was promoted to an Org, Level and / or (object dependently) whether the RESPOAREA is used.

A select on AGR_1251 is not enough - however ideally the * values for the old and the new concept should be in the same role and the user should have a minimal of single roles built using the same methodology for the objects.

Acid test as always is upgrades in SU25 for role quality issues...

Benchmark is one day to upgrade SU25 and adjust the roles to make them all green in expert mode for further maintenance.

For that you have to respect the PFCG merge rules and you must maintain SU24 and spend some time in Su25 step 2B.

Cheers,

Julius

Edited by: Julius Bussche on Sep 12, 2011 10:13 PM

[mvoros]

Sure David. I am on holiday at this moment so next release won\t be sooner than in October. Feel free to modify wiki and add a wishlist of additional features. Or just keep it here.

Cheers

[Former Member]

Pefect. It's working. However, few correction on the labels. In the inital screen, S_NAME should be modified and even the headings of the report should be corrected. Some of them are confusing.

Another recommendation - The Authority check statement (That checks S_TCODE with PFCG authorization) is done after selecting the role. Also, it simply closes the screen and comes back to easy access screen without an error message. Can this be further enhanced? Sorry.. im not an expert in ABAP.

Great Martin! Thanks again for the wonderful program.

Regards,

Raghu

Edited by: Raghu Boddu on Sep 13, 2011 9:11 PM. Added other recommendation

[mvoros]

Hi Raghu,

S_NAME - you have to maintain it by your self. I use standard text for that field. Check [documentation|http://help.sap.com/saphelp_nwpi71/helpdata/en/e3/960a0beb0711d194d100a0c94260a5/content.htm].

Which headings are confusing?

I'll fix this later but thanks for reporting this issue. I've never run it without access to PFCG.

Cheers

[Former Member]

The check on PFCG is IMO too strict. Any "on click" commands from the ALV would not need it either as PFCG generally checks itself in the target tcodes / FMs anyway.

A check against object S_ADMI_FCD action ACID would be correct

Cheers,

Julius

[mvoros]

As far as I remember I copied that code from one of the SUIM reports. I was looking for a method of displaying role in PFCG (there is no PID which can be used with statement CALL TRANSACTION) and I found that code. IMO it's a good check. If I understand problem correctly it should not terminate program if user does not have authorization for PFCG.

Cheers

[Former Member]

I agree with you. Actually I did not see the UC command feature.

What I meant is that the FM you use makes the check anyway using the authority check for tcode FM - so the targets are protected and can optionally create SE97 couples for contexts they trust. Hard coding cannot do that and sometimes bites back

In this case the PFCG checks are hard coded all over the place anyway and catching it earlier is easier as you do not have to catch exceptions.

The ACID admin function check was a little joke (related to toxin)

Cheers,

Julius

[mvoros]

> Would a check for the 5-6 objects relating to cost centres in derived roles be possible please?

Hi David,

could you elaborate this feature request?

Thanks

[Former Member]

Hi Martin

I was considering a check on derived roles containing cost centres to highlight the risk of over-writing but it would really be those such as SLOC etc but it is really only a nice to have I suppose!

Regards

David

[Former Member]

HI Martin,

The one suggested by David is a very good point. Lot of times we do have derived roles with few maintained values (Eg : Cost Centers) with a note [ Do not derive the Master Role ] in the roles to make sure we dont derive them and overwrite...

If we can get peice of code to identify this one too it would be a good enhancement. Thanks a lot for the nice utility.. Toying with it in Sandbox to get a hang of Toxicity in roles

Rgds,

Sri

[mvoros]

Sri and David,

I am not sure if I want to put that info in this report. As far as I understand your requirement you have derived roles with manually maintained values and you want to avoid overwriting these values. I just uploaded new version of report which has additional column "Type" (S - single, C - composite and D - derived). ow you can identify those derived roles because there is already check for fields that have manually maintained org. level fields. The new version has also additional field: "Number of assigned users". This might be useful for prioritizing issues if you push that report to production.

Cheers

[OttoGold]

Hi,

It is a pity that we spoiled this thread by debugging the ALV (release problem) or discussing column headers. The idea is cool but except the idea by David about the cost centers (which I didn`t understand, can I have a quick recap?) we weren`t able to come up with many new ideas (except ACID on 1251).

I am the guy who would rather develop the checks than suggest new, so it is so awkward trying to revive the discussion, but what do you guys fight every day? Do you have a company policy (or personal codex) on roles? Even if yes, it must be a tought call to force it, right?

Cheers Otto

[Former Member]

Hi Otto

I hate derived roles (amongst most things which make simple complicated) and one thing I dread is having a derived role's authorisation tab directly updated accidentally and then somebody not noticing that they are transporting an imparting role.

The other thing with derived roles is adding a transaction which SU24 then proposes an object containing, say, cost centres which are ususally maintained at object level (my current client has promoted them so not an issue at the moment).

Org levels are not over-written when cascading down from the parent/master but all of the unique object level entries are (including accidentally maintained org levels in object on the derived role I think?)

So, my comment was to check if any derived roles contain the usual objects related to cost centres - there are other too which I think may be storage locations and release strategies...and produce an amber warning (or what ever the output uses).

It's a nice to have as you can usually spot the little beggars a mile off when maintaining if you (a) spot the imparting role on the first tab, (b) spot there is no insert transaction option on the menu tab and (c) happen to see an entry in the imparting role at transport time

Still hate derived though...I vote that the report should have a big red error message for each one!

Kind regards

David

Edited by: David Berry on Nov 5, 2011 5:21 PM

[Former Member]

How about a preventative measure (as opposed to a detective reporting)?

Ask SAP to add 3 more IDs to PRGN_CUST:

DERIVED_CHANGE = 'E' will prevent menu and non-org field changes with an error. Default is 'W' (warning).

DERIVED_BLOCK = 'NO' will prevent roles from being derived.

COMPOSITE_BLOCK = 'NO' will prevent the creation of new composite roles in that system.

Perhaps also AUTH_CHANGE = 'E' will prevent "changed" status of auths. Default is 'W' (warning).

And... EDIT_OLD_STATUS = 'NO' will remove the option in the "expert" mode...

Any support for a development request / functionality wishlist entry?

Cheers,

Julius