Skip to Content

How mature is your authorization concept?

Authorization concepts are very often something like the unloved and underestimated child in many projects. But the increased compliance requirements and the need to ensure strict privacy and data protection mandate mature authorization concepts.

Therefore my colleagues, Troels Lindgaard from KMD and I have created a proposal for an authorization concept maturity model in a paper we recently published on SDN. Our goal is two folded: First we would like to enable you to assess the maturity of your current authorization concept. Such an assessment is the precondition to enable to support the compliance efforts of your organization. Second we have described suitable steps to jump from lower levels to a real mature authorization concept. We have combined our experiences from several projects and reviews to create this maturity concept. The model has already proven its benefits as we are using that model while working on these topics at several customers.

 But a lot of questions are still under discussion. Just some examples:

1.) Do we need a differentiation for smaller and bigger SAP installations?

2.) Do we need to differentiate the maturity concept for different industries and create industry-specific ones? 

Therefore we are really keen to get your feedback about our model.

You must be Logged on to comment or reply to a post.
  • A very important topic indeed - thanks for posting it.

    SAP has some dispairty in how security is treated between its different products. For example - implementation of ECC, BW and CRM security is different. The amount of trouble when we use these three together in a large implementation is big. For example, we had CRM access control engine for a project, and external users had access to CRM, BI and ECC through a portal. Ofcourse ACE works only for CRM and not for BI and ECC. We had to design complex workarounds to make sure that every body got their right access.

    I would seriously urge SAP to publish some best practices etc on such integration scenarios. I would think that these issues delay an organization from acquiring its mature security state.

    • Vijay,
      I completely agree with you. For example, we have complex cost centre authorisations in ERP - we do not want to replicate these in BI, the Security team don't want to do double maintenance in ERP & BI, nor do they understand the quite different BI authorisation concept. This constrains what we are able to provide from BI.
  • Hi Bernhard,

    The key to manage authorisations, is around the principles and methodologies applied to produce a list the security requirements. If IT are managing access profiles without adequate collaboration from the business, i can guarantee the authorisations model will be complex and potentially have significant security holes. It is in the best interset of the business to undestand their key enterprise and process level risks and based on their inherent exposures, develop their security requirements on that basis. This should help define whether an organisation large or small requires complex HR PD profiles, to analysis authorisation in BW etc etc.

    Agree with the previous posters before me, that there is an inconsistancy in the security framework within each of the SAP technologies. Its always nice to have a consistant approach, but in reality, our technologies demands and intentions are different from each other. That is why it is critical to step beyond the technical aspect and apply a top-down approach. This should not be indifferent for small or large organisations.