Configuring Resource Types

Resource types define a template for the resources that policies apply to, and the actions that could be performed on those resources.

For AM to decide if a user can access a resource, it requires a policy. When you configure a policy, you also configure a resource (or a pattern to match several resources) that the policy will apply to, and the actions that the policy allow or deny.

Resource types are templates that you can define once and reuse in several policies. For example, you could create a template that always PUT and POST operations from your internal network.

The default resource types that AM provides are enough for most environments.

AM includes two resource types by default: URL and OAuth2 Scope.

URL resource type

The URL resource type acts as a template for protecting web pages or applications. It contains resource patterns, such as *://*:*/*?*, which can be made more specific when used in the policy. The resource supports the following actions:

GET
POST
PUT
HEAD
PATCH
DELETE
OPTIONS

For example, an application for Example.com's HR service might contain resource types that constrain all policies to apply to URL resource types under http*://example.com/hr* and http*://example.com/hr*?*, and only the HTTP GET and POST actions.

AM also includes a resource type to protect REST endpoints, with patterns including https://*:*/*?* and the CRUDPAQ actions:

CREATE
READ
UPDATE
DELETE
PATCH
ACTION
QUERY
OAuth2 Scope resource type

The OAuth2 Scope resource type acts as a template for granting or denying OAuth 2.0 scopes. It contains a string-based scope pattern, *, and two URL-based scope patterns, such as *://*:*/*?*. The resource supports the GRANT action, which can be allowed or denied.

Configure resource types using the AM console or the REST API:

To Configure a Resource Type (UI)
  1. In the AM console, go to Realms > Realm Name > Authorization > Resource Types.

    1. To create a new resource type, select New Resource Type.

    2. To modify an existing resource type, select the resource type name.

    3. To delete an existing resource type, in the row containing the resource type select the Delete button.

      You can only delete resource types that are not being used by policy sets or policies. Trying to delete a resource type that is in use returns an HTTP 409 Conflict status code.

      Remove the resource type from any associated policy sets or policies to be able to delete it.

  2. Provide a name for the resource type, and optionally, a description.

    Do not use special characters within resource type, policy, or policy set names (for example, "my+resource+type") when using the AM console or REST endpoints. Using the special characters listed below causes AM to return a 400 Bad Request error. The special characters are: double quotes ("), plus sign (+), comma (,), less than (<), equals (=), greater than (>), backslash (\), forward slash (/), semicolon (;), and null (\u0000).

  3. To define resource patterns that policies using this resource type can expand upon, follow the steps below:

    1. In the Add a new pattern box, enter a pattern with optional wildcards that the policies will use as a template.

      Resource patterns can specify an individual URL or resource name to protect. Alternatively, a resource pattern can match URLs or resource names by using wildcards.

      • The wildcards you can use are * and -*-.

        These wildcards can be used throughout resource patterns to match URLs or resource names. For a resource pattern used to match URLs, wildcards can be employed to match the scheme, host, port, path, and query string of a resource.

        • When used within the path segment of a resource, the wildcard * matches multiple path segments.

          For example, http://www.example.com/* matches http://www.example.com/, http://www.example.com/index.html, and also http://www.example.com/company/images/logo.png.

        • When used within the path segment of a resource, the wildcard -*- will only match a single path segment.

          For example, http://www.example.com/-*- matches http://www.example.com/index.html but does not match http://www.example.com/company/resource.html or http://www.example.com/company/images/logo.png.

      • Wildcards do not match ?. You must explicitly add patterns to match URLs with query strings.

        • When matching URLs sent from a web or Java agent, an asterisk (*) used at the end of a pattern after a ? character matches one or more characters, not zero or more characters.

          For example, http://www.example.com/*?* matches http://www.example.com/users?_action=create, but not http://www.example.com/users?.

          To match everything under http://www.example.com/ specify three patterns, one for http://www.example.com/*, one for http://www.example.com/*?, and one for http://www.example.com/*?*.

        • When matching resources by using the policies?_action=evaluate REST endpoint, an asterisk (*) used at the end of a pattern after a ? character matches zero or more characters.

          For example, http://www.example.com/*?* matches http://www.example.com/users?_action=create, as well as http://www.example.com/users?.

          To match everything under http://www.example.com/ specify two patterns, one for http://www.example.com/*, one for http://www.example.com/*?*.

      • When defining patterns to match URLs with query strings, AM sorts the query string field-value pairs alphabetically by field name when normalizing URLs before checking whether a policy matches. Therefore the query string ?subject=SPBnfm+t5PlP+ISyQhVlplE22A8=&action=get is equivalent to the query string ?action=get&subject=SPBnfm+t5PlP+ISyQhVlplE22A8=.

      • Duplicate slashes (/) are not considered part of the resource name to match. A trailing slash is considered by AM as part of the resource name.

        For example, http://www.example.com//path/, and http://www.example.com/path// are treated in the same way.

        http://www.example.com/path, and http://www.example.com/path/ are considered two distinct resources.

      • Wildcards can be used to match protocols, host names, and port numbers.

        For example, *://*:*/* matches http://www.example.com:80/index.html, https://www.example.com:443/index.html, and http://www.example.net:8080/index.html.

        When a port number is not explicitly specified, then the default port number is implied. Therefore http://www.example.com/* is the same as http://www.example.com:80/*, and https://www.example.com/* is the same as https://www.example.com:443/*.

      • Wildcards cannot be escaped.

      • Do not mix * and -*- in the same pattern.

      • To match a resource that uses non-ASCII characters, percent-encode the resource when creating the rule.

        For example, to match resources under an Internationalized Resource Identifier (IRI) such as http://www.example.com/forstå, specify the following percent-encoded pattern:

        http://www.example.com:80/forst%C3%A5/*
      • By default, comparisons are not case sensitive. The delimiter, wildcards and case sensitivity are configurable. To see examples of other configurations, in the AM console, go to Configure > Global Services, select Policy Configuration, and scroll to Resource Comparator.

    2. Select the Add Pattern button to confirm the pattern.

    Tip

    To remove a pattern, select the Delete icon.

  4. To define the actions that policies using this resource type can allow or deny, follow the steps below:

    1. In the Add a new action box, enter an action related to the types of resources being described, and then select Add Action.

    2. Select either allow or deny as the default state for the action.

    To remove an action, select the Delete icon.

  5. Continue adding the patterns and actions that your resource type requires.

    Configuring Resource Types in the UI
    Configuring resource types in the AM console.

  6. Select Create Resource Type to save a new resource type or Save Changes to save modifications to an existing resource type.

Read a different version of :