Authorization

policies/authorization[]

The gateway can apply authorization rules to incoming requests. This entry defines a list of matching requests, rules and actions to perform if matches are found. The rules can be either:

  • Defined directly here in an entry.
  • Defined in the authorization section and reference by name here in an entry.

This entry defines authorization rules directly. There are also two pre-defined rules which can be used:

  • "anyuser" : Which allows access to any user, even if they are not authenticated.
  • "anyauth" : Which allows access to any authenticated user.

Properties

NameTypeConstraintsDescription
namestringA name for this policy, which is used to refer to this policy in audit events.
hoststringThe host (obtained from the host header in the request) for which this policy will be applied. If no host header is specified all hosts will be matched.
pathsArray of stringThe paths which this policy will be applied. Each path may contain the *? pattern matching characters. This entry is an array and can be used to specify multiple paths.
methodsArray of stringThe method(s) which this policy applies to. If this is not defined, the policy will apply to all methods.
rulestringIf a rule string is not defined here, the gateway will look for a named rule (with the same name as this policy) in the authorization section of the configuration YAML. Refer to the authorization section of this template for an explanation of rule syntax. The predefined rules anyuser or anyauth can also be referenced here.
actionstringValues: permit, deny, obligateDefines the action to perform if the rule matches. If the action is obligate, the obligation property must also be set for this authorization rule.
obligationobligation

policies/authorization[]/obligation

If the action for this rule is obligate, this obligation must be defined to indicate that authentication should take place again with specific parameters.

Note that a policy can only contain one obligated action, that is, this entry must contain oidc or redirect_url.

Redirect URL Macros

The following macros are available:

MacroValue
%USERNAME%The current logged in user, or unauthenticated for unauthenticated users.
%METHOD%The HTTP method of the request which matched this policy.
%URL%The URL the client was attempting to access when this policy was matched.
%HOSTNAME%The hostname (HTTP Host header) of the client request which matched this policy.
%PROTOCOL%The protocol (http or https) which was used
%CREDATTR{<attribute_name>}%The value of the credential attribute named by <attribute_name>.
%HTTPHDR{<header_name>}%The value of the HTTP header from the client request named by <header_name>.

Properties

NameTypeConstraintsDescription
oidcoidc
redirect_urlstringAllows clients to be redirected to a URL as a result of this policy evaluating successfully.
This URL can contain embedded macros to include contextual information about the request and client which was obligated to be redirected to this URL. See the Redirect URL Macros table above for the available macros.

policies/authorization[]/obligation/oidc

Authentication parameters which can be used when using an OIDC identity scenario. These parameters are passed as query string parameters when the authorization endpoint is requested.

Properties

NameTypeConstraintsDescription
acr_valuesstringA string of ACR (Authentication Context Class References) to pass to the identity provider. Refer to "acr_values" in section 3.1.2 of the OpenID Connect Core specification for further information.
Valid ACRs are defined by the identity provider. Refer to your identity provider for further information about the ACRs which it supports.
promptstringA string of prompt options to pass to the identity provider. Refer to "prompt" in section 3.1.2 of the OpenID Connect Core specification for further information.
Prompt options are optional and may not be supported by all identity providers. Refer to your identity provider for further information about support prompt values.

Example

policies:
  authorization:
    - name: policyA
      host: www.test.com
      paths:
        - /test*
      methods:
        - GET
        - POST
      rule: (any groupIds = "administrator")
      action: permit

    - name: policyB
      host: www.example.com
      paths:
        - /example*
      methods:
        - DELETE
      rule: anyuser
      action: obligate
      obligation:
        oidc:
          acr_values: "administrator mfa"
          prompt: login

    - name: mfa_required
      rule: 'acr = "urn:ibm:security:policy:id:2"'
      paths:
        - "/sensitive"
      action: "permit"

    - name: mfa_required_obligate
      rule: 'acr != "urn:ibm:security:policy:id:2"'
      paths:
        - "/sensitive"
      action: "obligate"
      obligation:
        oidc:
          acr_values: "urn:ibm:security:policy:id:2"
          prompt: "login"

    - name: eula_not_accepted
      rule: 'eula != "true"'
      paths:
        - "/application/*"
      action: "obligate"
      obligation:
        redirect_url: "/eula/landing?origin=%URL%&user=%CREDATTR{preferred_username}%&proxy=%HTTPHDR{x-ibm-proxy}%"

Did this page help you?