Skip to main content
Software Engineering

Return to Answer

deleted 562 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

For example

Application layerBlue & Green circles

In the application layer, weWe implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

Business layer

In this layer, we start speaking aboutThe CustomerRole and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of securitythe user can be implemented at this level too. For example, the business filters the data by its tenantthere can be different types of accounts (Admin, so outer layers are agnostic to data belonging to other tenantsCustomer, Provider, Guest). To make this seamless

If roles (accountabilities and responsibilities) are intrinsic to the application layerdomain or business, the application layer MUST identify the userwe implement these and retrieve the customer IDrules associated from the security contextin inner circles exclusively(red, yellow).

Domain layerRed circle

At the domain layerHere, we evaluate (among other rules or policies) the security is a bit blurredtenancy (data ownership). For example, in this layer,

  • CancelOrder use case evaluates OrderTenantcyPolicy and ConfirmationPolicy to validate the tenancy and evaluate the confirmation.
  • ListCustomerOrders use case applies OrderTenantcyPolicy to retrieve a very specific subset of orders.

Yellow circle

Here we might find the abstractionabstractions (ports) of those policies and business rules I mentioned previously. The concrete implementation Concrete implementations (adapters or use cases) can be located somewhere in theare left to outer layers (business, application, infrastructure, ...).

We don't make them concrete at this level because business rules and policies can change rapidlycircles for reasons unrelated to the domain. For examplecustomization and extensibility, we may need to add (or change) policies because we have implemented a new typebut the evaluation of Account (or Role). Or we want to make security more astringent, so we need to implement a new security policy handler (adapter) to solve howthese policies stack with others. This sort of changeand rules is unlikely to be caused by changes in the domain (what we do); the reasons are commonly associated with business changes (how we do it from now on)executed here.

Action Scope/Layer
Authentication AppBlue & Green
Authorize user to list "My Orders"execute CustomerOrderList use case AppBlue & Green
Retrieve orders by accountExecute use case security policies and rules BusinessRed & Yellow
Authorize user to execute CancelOrder use case AppBlue & Green
Execute cancel orderuse case security policies and rules BusinessRed & Yellow

Application layer

In the application layer, we implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

Business layer

In this layer, we start speaking about Customer and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of security. For example, the business filters the data by its tenant, so outer layers are agnostic to data belonging to other tenants. To make this seamless to the application layer, the application layer MUST identify the user and retrieve the customer ID associated from the security context exclusively.

Domain layer

At the domain layer, the security is a bit blurred. For example, in this layer, we might find the abstraction (ports) of those policies and business rules I mentioned previously. The concrete implementation (adapters or use cases) can be located somewhere in the outer layers (business, application, infrastructure, ...).

We don't make them concrete at this level because business rules and policies can change rapidly for reasons unrelated to the domain. For example, we may need to add (or change) policies because we have implemented a new type of Account (or Role). Or we want to make security more astringent, so we need to implement a new security policy handler (adapter) to solve how policies stack with others. This sort of change is unlikely to be caused by changes in the domain (what we do); the reasons are commonly associated with business changes (how we do it from now on).

Action Scope/Layer
Authentication App
Authorize user to list "My Orders" App
Retrieve orders by account Business
Authorize user to execute CancelOrder use case App
Execute cancel order policies Business

For example

Blue & Green circles

We implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

The Role of the user can be implemented at this level too. For example, there can be different types of accounts (Admin, Customer, Provider, Guest).

If roles (accountabilities and responsibilities) are intrinsic to the domain or business, we implement these and the rules associated in inner circles (red, yellow).

Red circle

Here, we evaluate (among other rules or policies) the tenancy (data ownership). For example,

  • CancelOrder use case evaluates OrderTenantcyPolicy and ConfirmationPolicy to validate the tenancy and evaluate the confirmation.
  • ListCustomerOrders use case applies OrderTenantcyPolicy to retrieve a very specific subset of orders.

Yellow circle

Here we might find the abstractions (ports) of those policies and rules I mentioned previously. Concrete implementations (adapters) are left to outer circles for customization and extensibility, but the evaluation of these policies and rules is executed here.

Action Scope/Layer
Authentication Blue & Green
Authorize user to execute CustomerOrderList use case Blue & Green
Execute use case security policies and rules Red & Yellow
Authorize user to execute CancelOrder use case Blue & Green
Execute use case security policies and rules Red & Yellow
added 339 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1).

Show Case

When should I, (...) deal with access control? For example, A customer can cancel an order, the Presentation layer takes care of the fact that they are a customer, they have permission to order with enough clearance to cancel one. But I also need to check that the Order they wish to cancel is owned by them, i.e. a matching AccountID between the user and order.

ActionScope/Layer
AuthenticationApp
Authorize user to list "My Orders"App
Retrieve orders by accountBusiness
Authorize user to execute CancelOrder use caseApp
Execute cancel order policiesBusiness

The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1).

Show Case

When should I, (...) deal with access control? For example, A customer can cancel an order, the Presentation layer takes care of the fact that they are a customer, they have permission to order with enough clearance to cancel one. But I also need to check that the Order they wish to cancel is owned by them, i.e. a matching AccountID between the user and order.

ActionScope/Layer
AuthenticationApp
Authorize user to list "My Orders"App
Retrieve orders by accountBusiness
Authorize user to execute CancelOrder use caseApp
Execute cancel order policiesBusiness
added 55 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

Security is a cross-cutting concern that can span several layers, and it does in different formats and ways from layer to layer.

Application layer

In the application layer, we implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

At this level, the entity associated with security is not the customer; it's the well-known Account. In a nutshell, and from the security context standpoint, there are no customers, only accounts and privileges.

The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

For multi-tenant accounts, for one user to act on behalf of a partner, it must do it through the proper security function, so the application security is always aware of who was authenticated and who is the enabled user at the time.

Business layer

In this layer, we start speaking about Customer and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of security. For example, the business filters the data by its tenant, so outer layers are agnostic to data belonging to other tenants. To make this seamless to the application layer, the application layer MUST identify the user and retrieve the customer ID associated from the security context exclusively.

Domain layer

At the domain layer, the security is a bit blurred. For example, in this layer, we might find the abstraction (ports) of those policies and business rules I mentioned previously. The concrete implementation (adapters or use cases) can be located somewhere in the outer layers (business, application, infrastructure, ...).

We don't make them concrete at this level because business rules and policies can change rapidly for reasons purely agnosticunrelated to the domain. For example, we may need to add or(or change) policies because we have releasedimplemented a new type of Account or (or Role). Or we want to make security more astringent, so we need to implement a new security policy handler (adapter) to solve how new policies stack with others. This sort of change is unlikely to be caused by changes in the domain (what we do); the reasons are easilycommonly associated with business motivationschanges (how we do it from now on).

The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1).

1: Conceptually simple, but complex to implement due to the so many abstractions, models, mappings, etc

Security is a cross-cutting concern that can span several layers, and it does in different formats and ways from layer to layer.

Application layer

In the application layer, we implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

At this level, the entity associated with security is not the customer; it's the well-known Account. In a nutshell, and from the security context standpoint, there are no customers, only accounts and privileges.

The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

For multi-tenant accounts, for one user to act on behalf of a partner, it must do it through the proper security function, so the application security is always aware of who was authenticated and who is the enabled user at the time.

Business layer

In this layer, we start speaking about Customer and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of security. For example, the business filters the data by its tenant, so outer layers are agnostic to data belonging to other tenants. To make this seamless to the application layer, the application layer MUST identify the user and retrieve the customer ID associated from the security context exclusively.

Domain layer

At the domain layer, the security is a bit blurred. For example, in this layer, we might find the abstraction of those policies and business rules I mentioned previously. The concrete implementation can be located somewhere in the outer layers (business, application, infrastructure, ...).

We don't make them concrete at this level because business rules and policies can change rapidly for reasons purely agnostic to the domain. For example, we may need to add or change policies because we have released a new type of Account or Role. Or we want to make security more astringent, so we need to implement a new security policy handler to solve how new policies stack with others. This sort of change is unlikely to be caused by changes in the domain (what we do); the reasons are easily associated with business motivations (how we do it from now on).

The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1)

1: Conceptually simple, but complex to implement due to the so many abstractions, models, mappings, etc

Security is a cross-cutting concern that can span several layers, and it does in different formats and ways from layer to layer.

Application layer

In the application layer, we implement how actors are authenticated (a way for them to prove they are who they claim to be and be electable to use the application) and authorized (a way to regulate the interaction based on rules or policies).

At this level, the entity associated with security is not the customer; it's the well-known Account. In a nutshell, and from the security context standpoint, there are no customers, only accounts and privileges.

The Role of the user is set at this level. For example, there can be different types of accounts (Admin, Customer, Provider, Guest, ...).

This gets more complicated if accounts support multi-tenancy (multiple users per account).

For multi-tenant accounts, for one user to act on behalf of a partner, it must do it through the proper security function, so the application security is always aware of who was authenticated and who is the enabled user at the time.

Business layer

In this layer, we start speaking about Customer and concepts like tenancy (data ownership) and business rules (or policies) that enact an additional layer of security. For example, the business filters the data by its tenant, so outer layers are agnostic to data belonging to other tenants. To make this seamless to the application layer, the application layer MUST identify the user and retrieve the customer ID associated from the security context exclusively.

Domain layer

At the domain layer, the security is a bit blurred. For example, in this layer, we might find the abstraction (ports) of those policies and business rules I mentioned previously. The concrete implementation (adapters or use cases) can be located somewhere in the outer layers (business, application, infrastructure, ...).

We don't make them concrete at this level because business rules and policies can change rapidly for reasons unrelated to the domain. For example, we may need to add (or change) policies because we have implemented a new type of Account (or Role). Or we want to make security more astringent, so we need to implement a new security policy handler (adapter) to solve how policies stack with others. This sort of change is unlikely to be caused by changes in the domain (what we do); the reasons are commonly associated with business changes (how we do it from now on).

The pitfalls are the same associated with abstraction and decoupling. In order to keep each security implementation decoupled but still highly cohesive across all the layers, we increase the global complexity of the application, which is per se, already complex (due to the CA1).

1: Conceptually simple, but complex to implement due to the so many abstractions, models, mappings, etc

added 55 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72