Page Comparison

...

This configuration requires two components:

1. Rule base authorities

2. Protected endpoints.

1- Rule base authorities:

...

Which can be translated to:

If IF token claims contains any of the next keys: contains a claim named token_claim_name_one OR token_claim_name_two, and the value equals

AND any of these claims have a value equal to expected_value_one OR expected_value_two then

THEN request will get GrantedAuthorityNameToBeAssigned as have a Granted Authority named GrantedAuthorityNameToBeAssigned.

Sample configurations:

oauth2:
  resource-server:
    authorization:
      rule-based-authorities:
        - authority-name: modelopEngineOnlyModelManage
          claim-value-condition:
            claims: user_id,client_id
            values: model-manage
        - authority-name: modelopEngineOnlyModelManageAndMlc
          claim-value-condition:
            claims: user_id,client_id
            values: model-manage,mlc-service
        - authority-name: modelop-monitor
          claim-value-condition:
            claims: user_id,client_id
            values: model-manage,mlc-service

...

{
  "issuer":"",
  "client_id": "model-manage",
  "created_date":"09/10/1986",
  "memberOf":"modelop"
}

The resulting Granted authorities will be:Every rule based authority will be granted because a client_id claim is present and equal to model-manage, causing the token to match each claim value condition. Hence, this token receives the following Granted Authorities.

modelopEngineOnlyModelManage,modelopEngineOnlyModelManageAndMlc,modelop-monitor

...

These protected endpoints are defined as a list of objects under gateway.security.protectedEndpoints:

gateway:
  security:
    protectedEndpoints:
    - grantedAuthorityName:

Each protected endpoint is defined by:

- required_granted_authority_name
      endpoints: comma_separated_list_of_endpoints

Pay special attention to the syntax and alignment when working with YAML object lists. Inline JSON-style syntax can be used if preferable.

gateway:
  security:
    protectedEndpoints: [ 
      { 
        grantedAuthorityName: required_granted_authority_name, 
        endpoints: comma_separated_list_of_endpoints
      }
    ]

Sample configurations:

gateway:
  security:
    # List of protected endpoints only available for Users with predefined grantedAuthorities
    protectedEndpoints:

      ## NOTE: The Order is KEY to have it working as expected , generic rules should be at the BOTTOM.
      ## Protected ModelOp engine TEST allowing access ONLY to ModelManage and mlc-service
      -
        grantedAuthorityName: modelopEngineOnlyModelManagemodelopEngineOnlyModelManageAndMlc
        endpoints: /engine-protected-modelop-test/api/roundtrip/0/1

      ## Protected ModelOp engine with wildcard allowing access ONLY to ModelManage and mlc-service
      -
        grantedAuthorityName: modelopEngineOnlyModelManageAndMlcmodelopEngineOnlyModelManage
        endpoints: /engine-protected-modelop-**/api/roundtrip/0/1

...

modelopEngineOnlyModelManage,
modelopEngineOnlyModelManageAndMlc,
modelop-monitor

Result:

The request will be able to access all endpoints because they require the modelopEngineOnlyModelManage and modelopEngineOnlyModelManageAndMlc authorities for access, both of which have been granted to the client.

Example 2:

Using the above configurations and receiving a token that generates the next granted authorities:

modelopEngineOnlyModelManageAndMlc,
modelop-monitor

Result:

The request wont will be able to access : the endpoint /engine-protected-modelop-test/api/roundtrip/0/1, but will not be able to access any other endpoints such as: /engine-protected-modelop-dev/api/roundtrip/0/1. The wildcard path pattern /engine-protected-modelop-**/api/roundtrip/0/1 would match the path /engine-protected-modelop-test/api/roundtrip/0/1, but because the more specific matcher is first in the list, it has precedence over the less specific matcher after it.