Can Spring Security OAuth2 authentication use a class/bean to add missing roles before URI pattern matching?

OAuth2 is used as one of the authentication modules available to external customer systems.
APIs are protected via the URI pattern matcher, so specific roles need to match for the request to succeed

SO using Azure AD, it's possible to define custom claims and map these to AD Groups, therefore matching the URI rules.

Apereo Central Authentication Service (CAS) connected to a LDAP server are not able to define custom claims or meet role requirements, therefore expecting the PASOE to do all the proper authorization.

When OAuth2 JWT token does not contain 'roles' claim it cannot match a URI rule
With OAuth2/JWT tokens something like a 'roles' claim is not common in an access_token/id_token.
Since a proper 'roles' claim is missing, requests get rejected by Spring long before hitting the Web Services ABL code.

To circumvent Roles 'permitAll()' and then reject requests in the ABL code where it's too late with APIs already exposed .

Example: The app expects 'roles' claim to be mapped into the Client-Principal:ROLES attribute with the following configuration, where the claim name is irrelevant. There is a possibility of mapping 'scope' which contains 2 values but these do not have the proper meaning in this example.
 

# oeablSecurity.properties:
jwtToken.defaultRoles=
jwtToken.usernameField=sub
jwtToken.mapScopeToRole=true
jwtToken.scopeToRolePrefix=
jwtToken.includeAllClaims=true
jwtToken.scopeNameField=roles

Whenever making a request containing the following token on the resource mentioned, it will fail due to the missing role 'User'. The problem here is that the issuer is unable to add roles, and expects our Application to do full authorization.

interceptor rule

"/web/Payroll/**","*","#oauth2.hasAnyScope('User')"

Access_token:

{
"sub": "test@xyz.com",
"roles": [ ],
"iss": "https://some-online-identity-provider"",
"aud": "some-unique-audience-value",
"scope": [
"b0dbb271-fd07-42bc-a64e-609b19574f7a/.default",
"openid"
],
...
}

 

Enterprise Authorization architectures two major categories when using an enterprise-scale Authentication process such as OAuth2.

1. The grants (aka Roles) used by authorization processes can be centrally managed by the enterprise, and it is the responsibility of the software product to use the grant names given to them.
We see this first style when the enterprise injects customer software product's roles into the security tokens they generate - where they are used in URL authorization expressions "#oauth2.hasAnyScope()" method.

2. The enterprise Authentication process issues security tokens without any grants, where the software product's authorization processes can validate an authenticated user token is present, but are then responsible for managing their own granting of roles.

This second style is sued where the enterprise chooses to require the software product to manage all of the user-account --> Role granting. Therefore, the "#oauth2.hasAnyScope()" methods will not be effective and another approach to authorization is needed. In this style, the first thing to do is to ensure a valid security token (OAuth2 access token) is being sent to the application. You would do this with the Spring OAuth2 expression "#oauth2.isClient() or #oauth2.isUser()" which ensures the OAuth2 bearer token is valid for either an abstract access token or an id token. In this way any unauthenticated access is rejected and when a client-principal is created the application already knows the token has been validated and its contents are valid for use.

The example provided has a scope that is an encoded identifier, which is usable only if it can be determined from the enterprise what it designates. It may be nothing or something. It would probably not be useful for finer-grained granting of rights to the application or data. We cannot tell that here, so it is a reasonable guess.

There are other Spring OAuth2 expressions, but they are all a variant of the enterprise injecting user grants into the token via the scope, roles, or some other field. Those checks can include RegEx pattern matching for more complex names.

Spring can reliably be used to minimally ensure a valid OAuth2 bearer token is received and create a client-principal containing the user's id. It can also do coarse-grained authorization using Roles if the enterprise injects Roles into its bearer tokens. When the token does not contain Roles, and Role-based-authorization is needed, then there has to be a source of that grants and a place where those grants are injected into the authorization process. The better approach would be to add an extension to the Spring process to use a source of user-to-role grants, which then make their way into the client-principal. 

Although OpenEdge can validate inbound OAuth2 tokens and pass requests through without URL authorization, the product does not currently have the functionality required to achieve this requirement. The product will have to be enhanced to add these features out-of-the-box.

It was determined that the Progress Product is functioning as designed.

An enhancement to the product can be requested through the Progress Community via an Ideas submission. Customer feedback is valuable and Idea submissions are monitored by our Product Management team. Enhancement requests are reviewed during the planning phase of each new product release and a list of the enhancements chosen for implementation can be found in the Release Notes documents that accompany each release. Once an Idea is submitted the Progress Software Community will have the opportunity to comment on and vote for the Idea.
 
For detailed information on how to submit an Idea, please refer to Article How to submit an enhancement request for a Progress product?.
 

Progress Article(s):
Sample for PASOE Support for JWT and OAuth 2.0