Security cross-cutting concerns

[emedina]

I have an application as a monolith that exposes a REST API and uses AuthN/AuthZ, where the request may come with one or two JWT tokens as headers:

• Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpX...
• External-Iduser-Token: eyJzdWIiOiIxMjM0NTY3OD...

The first token is an OAuth2 access-token, whereas the second one is a "custom" id-token that is generated from an "old" system. Eventually, when the request reaches the REST endpoint, we have a small logic to figure out what type of request this is based on the combination of those headers, and then we create the following representation (in Java):

	public class RequestType {

		private ClientType clientType;
		private String clientID;
		private String associations;
		private String associatedIds;

		private Role[] roles;
	}

We need such representation later when calling an external API to set it as parameters to an external URL. due to the way that this external API works (it requires setting the security params as part of the URL itself). Because this is now a monolith, it was easier for us to construct such representation in the MVC layer, then propagate it across all the layers (cluttering lots of services' methods with concerns that they are not actually interested in, though) into the final invocation of the external URL.

Now I would like to move all this to a hexagonal architecture, but I'm struggling with this specific concern, as based on my understanding:

1. The Security context is just another Bounded Context (BC) with its own model, which should not be coupled with my Domain Model.
2. Such Security context can only be generated at the MVC Layer, as it requires introspecting the HTTP request.
3. Such Security model should be an abstraction that somehow later should allow me to fetch it and convert it to the security params required by the external API.

So applying a hexagonal architecture and avoiding coupling between layers or managing concerns in layers where I shouldn't, my initial solution could be:

1. Create a Security (driving) adapter that acts as an HTTP web filter for any HTTP request that I get from the client UI, converts it into a RequestType (mentioned above), and stores/keeps it in its own separated BC.
2. Next, the HTTP request would reach my API (driving) Adapter, where I need to apply certain permissions based on the user's roles.
3. Last, as part of my use case, I would have to convert the Security model into the corresponding URL params to be able to invoke an external API through one of the Output Ports and its corresponding (driven) Adapter (as explained before).

Therefore, the following questions pop up:

1. Where do I intercept the security request? Because it's only available in the headers of the HTTP request, I would expect it to be some sort of Security (driving) Adapter that acts as (sort of) an HTTP web filter (prior to the API (driving) Adapter) that extracts the RequestType (mentioned before) and keeps it available in its own BC. Is this correct for an Adapter to behave as a Web Filter?
2. How do I integrate with such Security BC from both my API (driving) Adapter and (if needed) the Application Core? Should the API (driving) Adapter request the Security BC, then map it to an internal representation inside my Application Core using a DTO? If so, why would my Application Core be concerned about something that it's not needed inside the hexagon? Just to be a bridge to pass it over to the Output Port? Would this be a valid responsibility then?
3. Or should the API (driving) Adapter use the Security context, but then call the use case without it, so that the Application Core is unaware of it, and then the (driven) Adapter would have to integrate with the Security BC later? If so, wouldn't this break the architecture, as the (driven) Adapter would have to be aware of other Security (driving) Adapter, completely bypassing all the hexagon?

I'm a bit confused here, so any help would be greatly appreciated!

[Sairyss]

It's hard to tell without implementing it in code and experimenting a little bit.
If you need to get this tokens for every endpoint, the simplest solution that comes to mind is to use some kind of middleware that intercepts your HTTP request and extracts the token, converts it to the RequestType then sets it somewhere in a request context. When you need to call an external API with that RequestType you just get it from the context. This way you avoid propagating it everywhere.

why would my Application Core be concerned about something that it's not needed inside the hexagon? Just to be a bridge to pass it over to the Output Port?

Application services in the application core are just a bridge that orchestrates different parts of your applications, so IMO it's fine to do it in application services if you need to. But you could avoid that and just get the RequestType object from the request context in your output adapter, this way your application core doesn't need to know it even exists.

Here is some example code in typescript:

// Middleware that is executed before your request reaches your handlers
  use(req: Request, res: Response, next: NextFunction) {
    const requestType = convertHeadersToRequestType(req.headers);
    requestContext.set('requestTypes', requestTypes);
    next();
  }

// Adapter that calls external API
 const requestType = requestContext.get('requestTypes');
 // ... call external api with this request type

I guess in Java you could use RequestContextHolder ?
https://shzhangji.com/blog/2022/07/05/store-custom-data-in-spring-mvc-request-context/

[emedina]

Yes, this makes sense to me. We could think about all this Request Context as "infrastructure" outside of the Application Core, so just plumbing needed for the outer layers without impacting the inner layers in the hexagon.

Thanks so much for taking the time to reason about this with me!