UIU_COMP security question - is wildcard OK?

[Former Member]

I am trying to determine the risk or potential issues involved with setting this auth object to * for all fields.To avoid unexpected errors and ease testing time, it has been proposed on my team that this auth object should be set to * for all fields, because the business role will provide restrictions by function.

Anyone have thoughts or advice about setting all fields to * in UIU_COMP?

[Former Member · Accepted solution]

Thanks Leon. After posting this I did find other threads stating that it may be alright to give wildcards for this authorization, since it may provide only GUI elements and not the underlying authorizations that control CRM functionality. The wiki link you found seems to support this. So I'm wondering if visibility to GUI elements is not critical or confusing to users, is it alright to open this up? Anyone have hands on experience with this?

[stephenjohannes · Accepted solution]

Normally I would say don't wildcard anything, but this authorization is probably the exception to the rule. If you want to be really secure you can create the component defintion for this but... it's going to be a pain if you use a lot of CRM functions. The way most people do it is star this out and then just simply let the business role menus control navigation etc.

If you want to narrow this down, then the report CRMD_UI_ROLE_PREPARE can help reduce the need for wildcards, but keep in mind that you will probably have over hundred different components depending on the business role.

I would more focus on securing who can assign business roles to users in production or that model rather than this authorization object. The UIU_COMP does not restrict access to data, but rather just attempts to restrict navigation. The problem is that since a UI link could call 20 or 30 different components(say account data) this becomes messy. It's just another option if you don't want to use multiple business roles, or need to reduce the number of business roles, but still I think its a very messsy approach.

Thank you,

Stephen

[Former Member · Accepted solution]

Thanks very much, Stephen... this is exactly the kind of first hand experience I was hoping to gain from the forum!

Since you mentioned CRMD_UI_ROLE_PREPARE.... we have been building PFCG roles from scratch, and the technique used so far is to import the menu of a SAP role (that we created with CRMD_UI_ROLE_PREPARE) into our custom role. For example, we may import the menu of SAP_CRM_UIU_IC_MANAGER into our custom role. Then we set initial auth values, and test while a security trace is active to capture any other needed auths. What do you think about this approach? We do this because the SAP Business role mappings to SAP roles don't fit how we use CRM. In some cases it's close, but not perfect enough to align business role exactly to a PFCG role. Curious if our approach has any flaws that we have not considered.

[stephenjohannes · Accepted solution]

Building the roles by hand is fine. Personally most security folks I know have never seen an SAP delivered role that they like and since they are building it I agree.

One thing I want to mention which would save much, much time in long term maintenance is the following:

1) CRM Security roles assigned to users should be a composite role

2) Each business role should correspond to exactly one CRM Composite role

The reason being is that you will find that all users will need to view business partners but will vary in the types of transactions and other areas. You can then also reuse build up or deploy new modules of CRM easier by having a layered composite approach.

The idea is that you have a basic function role, followed by more specific roles until you reach the business specific role that causes it to be composite. That way say that right now you are only implementing Sales and Marketing, you don't need to change say 6 security roles at he detail level and instead can just add a new service role to those parts of the business that need it.

So as long as you try to not make all your roles assigned to users huge monoliths, then building them manual as you described should work.

Take care,

Stephen

[Former Member · Accepted solution]

The issue here, I think, is that we have promoted a couple objects to org.fields, in order to provide custom views for different regions. IC Reps, for example, may be mapped to the same business role, but get assigned a different derived single role based on their location.

I see what you're saying about using composite roles though. The mapped roles would contain base functionality for the business role. Need to give that some thought.

Thank you for this advice.

[Former Member · Accepted solution]

I do not agree with the * value in UIU_COMP, except if your company would have a strategy where a group of users (function) would always have their own separate business role, so by having their own navigation bar profile and business role customizing you already can "authorize" what these users will be able to see and use as functionality. Also, only in those scenarios I think the report CRMD_UI_ROLE_PREPARE has a somewhat useful purpose.

Other than that, I would never use this kind approach.

In larger companies, this would mean you would need a great number of business  roles just to cover your authorization requirements, unless you can live with the fact that people can just see irrelevant workcenters and navigation links in their CRM WEBUI menu, that I can not really use.

The advantage of always using UIU_COMP  (where you explicitly work with the fields Component/WindowName/Inbound plug)  is particulary useful, if you have multiple groups of people that actually can use the SAME business role (e.g. sales) but where through the usage of UIU_COMP I determine by each the composite PFCG roles which user group can see which workcenters and navigation links.

In that case, using the report CRMD_UI_ROLE_PREPARE is quite useless, as this just reads your business role customizing, puts the relevant external services in a txt-file which you then would upload in 1 single and very large PFCG role, which hardly can be considered as normal way of setting up a decent authorization concept, where you typically create a function /task matrix and build task roles..

2nd: the report does seem to include really a lot of irrelevant and unnessary authorization objects , so you still need to figure out for yourself what authorization object serves which purpose. e.g. I can build a business role for sales scenario, with NO marketing and campaing management /segment builder and other related MKT stuff., but still the report would include a lot of typical marketing related authorization objects.

cheers

Davy Pelssers

[Former Member · Accepted solution]

Hello,

I have been building PFCG and Business Roles for a project for the first time - I have more or less been using my knowledge of Role authorization concept (think Portals or SAP In-Store Merchandise and Inventory Management (formerly Retail Store) products).  I inherited CRM Business Roles that had been set up by consultants who have long rolled off the project and some of the roles did not have menus and none of them had UIU_COMP authorization objects.  I have gotten to the point now where I have PFCG Roles with menus and UIU_COMP objects. 

Based on my CRMD_UI_ROLE_PREPARE results, I have over 500 lines returned for one role - which results in approximately 350 single UIU_COMP objects needed.  There is a limitation of 100 such objects - so, I did an evaluation and condensed as many of the components/plugs/windows as possible, but it seems I am still exceeding my number of UIU_COMP objects available.

One colleague suggested that there is a way to add another instance of UIU_COMP at the higher level so I could have 100 more available objects - is there a way to do this or do I have to convince my customer to remove some of the "Home" work center objects or the Home work center all together? 

Any suggestions would be most appreciated!

Best regards,

Maureen

[former_member13738]

Hi Schweitzer,

It is always advised "Never ever use wildcards for all auth objects".Auth objects are delivered for a

purpose.

By giving wildcards to all objects, you are just disabling the authority check mentioned specific for

different business roles. This gives access to all users authority to do actions which are restricted

to them. It will have a lot of business impact.

So it is advised to provide specific set of values for auth objects initially itself even though it is pain and

takes time. Later it add value to your business and ease of use. Otherwise you will get into trouble later.

You can get more details from the links:

[http://wiki.sdn.sap.com/wiki/display/Security/QAMetricsforRoleDesign|http://wiki.sdn.sap.com/wiki/display/Security/QAMetricsforRoleDesign]

[|]

[http://tisc-insight.com/newsletters/316.html|http://tisc-insight.com/newsletters/316.html]

[http://wiki.sdn.sap.com/wiki/display/SMAUTH/UIU_COMP|http://wiki.sdn.sap.com/wiki/display/SMAUTH/UIU_COMP]

Regards

Leon