Internal OAuth2 architecture
ModelOp Center adheres to the Spring Security Architecture for OAuth2 applications.
The next diagram provides a high level overview of the internal layers.
Â
Â
ModelOp Center supports ServerHttpSecurity configurations as:
OAuth2Login (C2B):
Mainly used by the Gateway, handling browser authentication.
ResourceServer:
Jwt:
Token local validations performed by JWKs.
Opaque:
Token validations performed by introspection; through token introspection resolvers ( in case more than one token introspection defined ).
Opaque-QueryParam.
Securing microservice to microservice communication
In secured environments, microservice to microservice communication or B2B communication is token protected. This process is internally managed by feign
clients. Feign clients use an OAuth2 FeignInterceptor
implementation in charge of requesting/refreshing tokens and adding them as headers as part of each request.
To improve performance, our FeignInterceptor
is adding an additional tenant-id header inside the request, allowing downstream resource servers (RS) to identify faster the right introspector/token validator to be used at runtime, saving time and resources, specially when used with Opaque environments with multiple OAuth2 IdP defined.
Defining a MicroService as Resource Server (RS):
Identify the type of tokens to be supported
Define profiles accordingly
Add required YAML configurations.
Currently, three types of resource servers are supported:
JWT
Opaque Token
Opaque Query Param (This is a non-traditional type of Opaque Token required for one of our clients, and it is not used locally).
All of these resource servers share the following common configurations:
oauth2:
feign:
client-id: ${modelop.mm.client-id}
client-secret: ${modelop.mm.client-secret}
access-token-uri: ${modelop.provider.token-uri}
scopes: ${modelop.mm.scope}
group-base-access:
oauth2-group-claim-name: memberOf
admin-default-access-group: admin
default-access-groups: ${oauth2.group-base-access.default-access-group}
JWT RS configurations
JWT RS is straight forward, only jwt
profile is required.
spring:
profile: secured, jwt
# Oauth2 Resource server PF Configuration
security:
oauth2:
resourceserver:
jwt:
issuer-uri: https://authorization.server
oauth2:
resource-server:
jwt:
enduser-claimname: endUserClaimName
oauth2client-claimname: oauth2ClientName
scope-claimname: scp
base-conf:
enduser-claimname: endUserClaimName
oauth2client-claimname: oauth2ClientName
Opaque token RS configurations
At least one default RS opaque configuration is needed under
spring.security.oauth2.resourceserver.opaque-token
, so that related spring OAuth2 dependencies are properly instantiated.
Default configuration example:
spring:
profile: secured, opaque
# Oauth2 Resource server PF Configuration
security:
oauth2:
resourceserver:
opaque-token:
#Default opaque introspector
introspection-uri: ${modelop.mm.introspection-uri}
client-id: ${modelop.mm.client-id}
client-secret: ${modelop.mm.client-secret}
client-registration-id: springClientRegistrationId
client-registration-id needs to point to a valid spring client registration id.
Adding additional Opaque RS introspectors:
ModelOp Center is able to handle additional Opaque introspectors for token introspection.
These introspectors can be defined under oauth2.resource-server.opaque
:
As a rule, each of the additional introspectors defined, need to be mapped with a Spring Client Registration associated with the same clientRegistrationId.
Opaque Query Param
ModelOp Center is able to support and introspect some non-standard OAuth2 idPs. By default ModelOp Center provides an implementation for a Opaque Query Param introspector, that can be defined as:
Token Claims to User Attributes Mapping
By default, ModelOp Center maps each user attribute to its corresponding standard claim. The standard claims used by ModelOp Center are defined in the OpenID Connect specification as a set of OpenID Connect Standard Claims. For the complete list of standard claims, please refer to section 5.1 Standard Claims of the OpenID Connect specification.
ModelOp Center’s default use of the standard claims can be adjusted to use other claims by adding configuration properties. For example, the standard claim for a user’s given name is given_name
. However, if that particular claim is not available, one could use the username
claim instead (assuming the claim is available) by adding the following configuration properties:
Please note that the configuration above is overriding one claim name only, but multiple or all claim names can be overridden, if necessary.