This article looks at a new concept for creating application security context models for modern solutions using best practice security. By using security context models in projects, a qualitative and secure authentication solution can be produced quicker and more efficient. At present, too many solution architects try to patch the security architecture after the application architecture has been completed.
Goal of the model
Modern application security solutions have evolved to utilize a zero trust approach instead of relying on security perimeters. This shifts the focus to authentication and authorization flows rather than network or firewall protection. Security measures are now enforced locally on each component, rather than just at the front door. In order to implement this new paradigm and move away from the traditional boundary thinking, a modeling concept known as security context models can be used. These models provide a framework for understanding and addressing security concerns in modern applications, by placing authentication and authorization at the center of the security architecture model.
Benefits of a security context model
Security architecture part of the solution and not “fixed” after with weak workarounds.
Security reviews can use this and produce more output, less time is required re-modelling the solution.
Complex security flows or incorrect security concepts can be identified early.
Application security support simplified.
SAST: white box testing can use the model and focus.
What information is important in a security context diagram?
A security context model
- displays interfaces with third party applications and security definitions
- displays the authentication and authorization clients
- displays the application and delegated client types (app identity or app+user identity)
- displays private zones, public zones and security zones
- displays the authentication and authorization flow types
- has an appendix
Display interfaces with third party Apps and security definitions
The interfaces between the relevant internal and external components should be displayed in a context security model. By displaying the interfaces further security information can be included and displayed. Including the interfaces, the different security flows can be identified. Here’s an example displaying only the interfaces. From this model alone, it is clear that only Keycloak clients are used and the Keycloak identity provider federates to the further identity providers.
Displays the authentication and authorization clients
It is very useful to display the authentication and authorization flow type definitions. You should also specify if a client is a single tenant or a multiple tenant client. A security client should be either a delegated or an application type. In Azure, it is a good idea not to mix the application and delegated permissions in a single client which can lead to security problems.
Display application and delegated client types
The application or the delegated (user) types can be displayed in the model to add clarity to the API access. An access token returned to a UI client flow type is always a delegated (user + identity) access token. If the client credentials flow is used, then the access token is created for the trusted application and no user is involved. You could display the client inside the application and add an application access token to the model or I sometimes just display the flow type in the connection and it is clear that an application token is used to access the API.
Displays private zones, public zones and security zones
The public or private zones should be displayed in a security context model. Firewalls can also be included to enrich the model but these are not required. Any component which implements part of the authentication or authorization should be included. If it makes it easier to understand the security architecture, it should be included. By including the security zones, you can see clearly which components are accessible from the internet or intranet or separate networks. This does not change the security requirements of each component as each component needs to implement the security anyway (Zero trust strategy).
Displays the authentication and authorization flow types
It is important to include the authentication and the authorization flow types to acquire access tokens, or access to UI applications. Only standards should be used and a client application should never create it’s own access tokens. In the following model, the client credentials flow is used to request an application access token to access the API application.
Should I include network security components?
Traditional security boundary models were created with the firewall rules and definitions to control the traffic. These models are still required but have a different focus. In an application security context model, only the network components used to implement authentication or authorization components are included. If you use an API manager to implement an OAuth2 client for the API application, then this needs to be included. If you use an application proxy to remove or add HTTP security headers, this should be included as well.
Example Security Context for Web application using BFF (Backend for Frontend)
A Blazor application is implemented using BFF security architecture. The Blazor application uses a downstream API which authorizes using delegated user access tokens. The API application uses an Azure SQL. The API and the database are not public to the internet.
Security context model appendix
Interface 1 Blazor – Key Vault
Access using service managed identity with restricted access
Interface 2 API – Key Vault
Access using service managed identity with restricted access
Interface 3 Blazor – API
OAuth using delegated user access token and scope. The API is restricted for use with the Blazor UI using the Azure App registration clientId
Interface 4 API – SQL DB
Access using service managed identity with restricted access
Interface 5 Blazor – Azure AD
OpenID Connect code flow with PKCE, confidential client
Links
https://learn.microsoft.com/en-us/azure/security/fundamentals/zero-trust