Mobile Search Mobile Menu

By Simeio

Why is Dynamic Authorization Such a Big Deal? 

This week we bring you another informative Coffee Talk session. Last Wednesday’s topic was “Why is Dynamic Authorization Such a Big Deal? The session hosts were Roland Davis, Sr. Product Manager at Simeio, and Jon Stinnett, Channel Solutions Architect at Ping. Here are some session highlights. 

What is dynamic authorization, and why is it so important?  

Dynamic authorization can be characterized as constant change in granting access to business resources. Within an environment of constant change, we need real-time enforcement of fine-grained access control, with business logic around what users can see and do, including the context and purpose. We need to externalize authorization from individual applications, APIs, and other resources that users might be accessing. And we need to manage everything from a centralized location.  

What we see today is a shift in how applications are being developed, and how companies are thinking about securing their environments. The traditional castle and mote approach trusted everyone inside the castle, but trusted no one outside. That has largely shifted because of many factors, like cloud and mobility, that impact trust outside of traditional corporate walls. This open perimeter environment has made dynamic authorization more relevant, because companies no longer have the same control they once had, over remote users accessing systems and data. Now you need to move those authorization decision points closer to the applications themselves. Additional business rules and logic need to be implemented for greater control over who has access, and what they can do. The challenge for many organizations is how to manage those rules.  

What are the concerns around implementing new rules and complex logic, and how are they addressed? 

Role-based access controls tend to be static, and have an all-or-nothing access approach. In business, things are constantly changing, and we need to limit authorization sprawl. For example, an engineer may have access to XYZ data, but someone else with that same role may need added privilege to access additional data for a special project.   

When we switch to a more fine-grained approach, like attribute-based access control, we can dive deeper into more complex policies and rules that need to be implemented in today’s open perimeter environments, and allow, block, filter, and obfuscate any type of data.  

This allows us to accomplish a couple of things. We limit authorization sprawl, and put policies into a central system that various business stakeholders can easily work on together.  They can visualize the policies, and gain an understanding of what is important to them. This removes the burden from developers, that may not know what is important to the business stakeholder. It also allows us to move into the area of compliance, where data privacy enforcement and consent rules can be implemented within a central location, where business-unit stakeholders can implement greater and more specific controls.   

Traditionally, developers have been responsible for the authorization decision and enforcement points. When you multiple that out to the myriad applications across an organization, it becomes quite difficult to manage. With role-based control, there is constant care and feeding that needs to be done, if there is a change in how access is provided to an application.  It also requires back-and-forth communication between the application team for things like feature requests, that need to be brought to the software vendor, SaaS service, or in-house dev team. When you multiple this across many applications, you can quickly see the need for centralized and fine-grain control over operational rules and business policies for authorization. Driving dynamic authorization through attributes, is really the better and faster way to have controls in place over your applications, no matter where they reside. Adding people to a role has a lot of overhead associated, and requires a lot of engineering of the right roles, and who should be included with those roles. Whereas, using attributes is much more effective in addressing complex business logic, that goes well beyond user profiles. Attributes can include users, devices, networks, and locations. Dynamic authorization also plays a role in Zero Trust enablement.  

Some naysayers might counter the idea of moving policies and making additional queries into a centralized system that is far from the application. They might be concerned about performance because of additional logic checks across different attributes. Will there be added lag time for logging in? Will they be opening up security risk by adding this new centralized system?  

While performance can be a concern, there are techniques that can help overcome potential performance issues, like caching, and utilizing graph databases to speed performance. There are also solutions that use distributed policy decision and enforcement point architectures. These move the policy decision points closer to the applications, so the application decision end-point and policy decision end-point are closer from a network perspective. Also, the policy decision end-point has a set of rules setup specifically for the application. From a security standpoint, these systems use industry standard security, and have strong security practices.  

Can you provide some examples of how dynamic authorization has been implemented by other organizations? 

There are three verticals that come to mind. One example is Telehealth, with doctor meetings over Zoom-type applications. Dynamic authorization can ensure consent for third-parties, like other physicians or family members, with access to medical records, without seeing more than they actually need to. Dynamic authorization also works well in supporting industry standard specifications that help deliver services, like FHIR HL7.  

Customer service is another example, where a customer calls in with an issue, and they need to authorize the customer service representative to see their information. This might require a financial advisor to see a particular savings account, but not the checking account. Dynamic authorization can help provide the right levels of authorization for this use case.  

A third example is Open Banking, where the user logs into a single pane-of-glass that ties into all of their bank accounts, like checking, savings, 401K, etc. Dynamic authorization can be used to determine what levels of access are granted. They can limit how far back in time the rep is able to see account data. Dynamic authorization supports digital financial services that use open APIs that enable third-party developers to build applications and services. This helps support greater financial transparency for customer data, while protecting data privacy. 

We’ve just touched upon some of the conversation. If you want to learn more, you can watch this, and other on-demand Coffee Talk sessions at

We hope you can join our next Coffee Talk where you can chat with IAM experts, ask questions and gain insights into how you can lower operational costs, and achieve greater security and privacy using IAM. Click here to sign-up