Try OpenEdge Now
skip to main content
New Information
Progress Application Server for OpenEdge : Authentication with OAuth2 and JWT : Configuring a PASOE Web Application as an OAuth2 Resource Server : Authorizing Access to URLs and HTTP Methods
 
Authorizing Access to URLs and HTTP Methods
The OAuth2 Access Tokens do not contain user-ids and roles, in the traditional sense, for authorizing access to resources. While a user-id exists in a Self-contained Access Token for logging and audit trail use, it is not used outside of that scope. Instead OAuth2 uses the notion of client-id and scope to authorize a particular client (application) to use the Resource Server and defines what operations a Resource Owner has authorized the Resource Server to perform for that client.
So the traditional Spring Security Role-Based-Authorization (RBA) and its configuration do not apply to OAuth2. Instead a new form of authorization access control and configuration is used by Spring Security to grant the right to perform an operation.
Basically, OAuth2 authorization is configured using a file named WEB-INF/oeablSecurityJWT.csv. It performs the same basic function as the traditional RBA configuration file oeablSecurity.csv.
The format of oeablSecurityJWT.csv has the same three double-quote fields that hold the URI, HTTP-Method, and access-control specification. The first two fields ( URI & HTTP-Method ) are the same as in the RBA’s oeablSecurity.csv. The third field holding the access-control specification uses a different Spring Security expression language.
The expression language used for traditional RBA and OAuth2 scope authorization share the concept of testing whether a security token has been granted a name, and that name corresponds to granting access to some process, function, or data. A name is just a name, so long as whoever grants the name and the resource server who associates it with access to some resource agree on what the name is.
In the case of OAuth2, the name is an OAuth2 scope that the Authorization Server inserts into the Self-contained Access Token as directed by the Resource Owner. So the same rules apply as with RBA, the Resource Server’s configuration has to use the scope names configured and used by the Authorization Server. In live production environments, that information will have to be obtained by administrator.
The format of an OAuth2 access-control expression is:
access-control-expr := “ oauth2-spec [ { or | and } oauth2-spec ... ] “
oauth2-spec = #oauth2.test( ‘value’ [, ‘value’... ] )
The following table is a list of tests:
clientHasAnyRole(‘name’...)
Check if OAuth2 client has one of the listed Role names
clientHasRole(‘name’)
Check if the OAuth2 client as the specified Role name
denyOAuthClient( )
Deny access to all OAuth2 clients, but allow other types of clients
hasAnyScope(‘name’ ...)
Check if the OAuth2 client has any named scope specified
hasAnyScopeMatching( ‘reg-ex’...)
Check if the OAuth2 client has one of the scopes matching a specified regex expression
hasScope(‘name’)
Check if the OAuth2 client has the named scope specified
hasScopeMatching(‘reg-ex’)
Check if the OAuth2 client has a named scope matching a specified regex expression
isClient( )
Check if the request is from an OAuth2 client (and not another type of user)
isOAuth( )
Permit only OAuth2 type requests
isUser( )
Check if the current request is from a user and not from an OAuth2 client
Each test returns true/false, and the entire expression must return true in order for the Resource Server to grant access.
In the default distribution of oeablSecurityJWT.csv the default scope names are:
*PSCUser
*PSCAdmin
*PSCDebug