authz Archives - IDPro https://idpro.org/tag/authz/ The Professional Organization for Digital Identity Management Wed, 15 Apr 2020 19:24:39 +0000 en-US hourly 1 https://idpro.org/wp-content/uploads/2023/07/cropped-idpro_stickerA-circle-100-32x32.jpg authz Archives - IDPro https://idpro.org/tag/authz/ 32 32 Authorisation: Practices and Politics https://idpro.org/authorisation-practices-and-politics/ https://idpro.org/authorisation-practices-and-politics/#respond Wed, 10 Jul 2019 21:30:00 +0000 https://www.idpro.org/?p=663 “I can’t do authorisation – it’s way too close to the business.” This quote, ventured by a colleague, exemplifies both […]

The post Authorisation: Practices and Politics appeared first on IDPro.

]]>
“I can’t do authorisation – it’s way too close to the business.” This quote, ventured by a colleague, exemplifies both the opportunity and challenge of providing authorisation services in an enterprise context. Anyone taking on this space can expect to gather insights into business processes at a breadth and depth few enterprise services afford. At the same time, reluctance from both developers and product owners will require a level of salesmanship few of us are used to. Why is that?

Don’t touch my authorisation

Two key factors appear to give application teams pause when asked to let another team take care of the decision of who can do what within their application. First, authorisation immediately impacts the user flow. In an ideal world, nearly all of the user interface will be driven by the level of access users have been granted. After all, no one likes a pop-up saying “access denied”. For most users, ignorance as to what they don’t have access to is bliss. For an application rich in features and data this means many round-trips to the authorisation service until the canvas is populated.

Second, quite a few application-level authorisation services appear to have grown out of what was fundamentally a data management challenge. Take for example the contract management system for corporate payment services. The contracts are highly structured and, among other data points, contain payment limits, four-eyes requirements for specific payment types, etc. Initially, the system captured this information to generate contracts. These days, the same system exposes part of the contract as authorisation information for payment-related applications. Asking the product owner to access this contract data from an enterprise authorisation solution is bound to make them nervous. Many others feel the same.

From the perspective of someone running an enterprise-wide programme, this reluctance to engage creates challenges. Responsibilities to manage the line of business-specific authorisation information, and structure rarely map neatly to enterprise-level responsibilities. This complicates business-as-usual processes. And while authentication, request and approval, or governance are lower-order systems integration challenges, ex-post integration of application-level authorisation requires a level of effort that threatens the overall business case.

For the record, a centralised authorisation service provides many benefits for the organisation. Greater consistency, ease of integration with the remainder of the identity and access management solutions, single point of implementation for corporate policies being a few worth noting. Enterprise authorisation, thus, approximates a key challenge familiar to any economist: Rational decisions at the application level lead to sub-optimal outcomes at the enterprise level. 

Try, fail, rinse, repeat

Trying to wrestle this to the ground led to the E-TERRA approach. Through a series of conversations it became clear that the single-application authorisation solution, while far from dead, was not the norm. Instead, applications supporting the same business process appeared to have clustered around a limited number of authorisation solutions. Their owners, in turn, wrestled with the increased complexity as well as the user experience when it came to actually getting access. Building on this, the approach was structured as follows. 

Explore: The first step is to survey the landscape and build an understanding of the specifics of the most successful services. It also helps owners to realise that others are wrestling with the same challenges.

Target: This phase essentially answers the question “What does good look like?” The box highlights a few implementation details good authorisation services seem to share.

Educate: While they feel a sense of ownership, developers rarely burn for authorisation. Helping them understand the specifics of a solution and how to integrate goes a long way. Sequence diagrams, API documentation, and configuration information for their favourite hosting environment appear to be good starting points. Make them available in a central location.

Reference: Functional access is usually highly specific to the application. Data access (as highlighted above) is frequently shared across a business process. Integrating the relevant data sources into the authorisation service as reference data is key to success.

Rationalise: Now is the time to start joining forces across authorisation services to reduce duplication and focus efforts. This phase should not be contentious as at this stage, owners of the authorisation services will have worked together for a while and built a measure of trust.

Administer: A solid business-as-usual process bookends the approach. It is important, however, to note that this will need to accommodate business administrators to ensure the authorisation service can deal with the complexity and speed of today’s enterprises.

Success – now what?

If (and it’s a big if) the E-TERRA approach succeeds, the time will come that one solution will be declared legacy in favour of a more strategic one. Incidentally, sometimes this happens even in the absence of a structured approach, be it due to key team members moving on, budget pressures, or whatever else, leading to a rethink of strategic priorities. This is the time of transition and migration – which has its own set of challenges.

More successful solutions will have achieved a degree of integration with the remainder of the platform, whether it is authentication, request and approval, or provisioning. Application teams will take this for granted. Key success factors for a transition project are:

  • a full understanding of the scope of the legacy solution and their integration points with the platform (such as authentication or provisioning);
  • an internal transition management that coordinates the migration of identified integration points; 
  • leveraging the existing configuration to drive on-boarding (eg. request and approval) instead of starting from scratch; and 
  • being prepared for internal and external road-blocks such as budget challenges.

Finally, it pays to understand key stakeholder concerns which tend to focus on lead-time to allow for proper planning and the benefits to be achieved.

In closing, it stands to reason that authorisation is one of the most exciting spaces to be in as it provides for a rich blend of technical and business challenges. To quote another colleague “So now we are talking political architecture?”

Olaf Greweis the Head of Authorisation Solutions at Deutsche Bank and a founding individual member of IDPro.

The post Authorisation: Practices and Politics appeared first on IDPro.

]]>
https://idpro.org/authorisation-practices-and-politics/feed/ 0