hexa-org/policy

Repository for development of IDQL Policy Language

policy's Issues

Add Query components to Actions

*Please provide some basic information describing your suggestion
The current spec does not allow the ability to define allowed queries (URL items after ?).

Describe the change you would like to propose
Proposal to add a map called "query" that is a map of attribute names and regex patterns for value. An empty or * value shall mean any value accepted.

What do you feel is the ideal solution?

What would be a minimal or good enough solution if any?

Additional context

Using Scope as Query Parameters

*Please provide some basic information describing your suggestion
Proposal: For a http request, scope name value pairs could normally be appended or override API query parameters. For example a scope of "country":"eu" could be appended to a url:

Before:
http://www.canarybank.io/customer/353210057?username=alicesprings
Becomes:
http://www.canarybank.io/customer/353210057?username=alicesprings&country=eu

Currently scopes are defined as variables applied only to actions or conditions. It turns out that run-time variable substitution in actions/conditions may not always be possible.

Is Subject Type Needed?

*Please provide some basic information describing your suggestion
In Section 4.3, there is a sub-attribute called subType which indicates the type of subject. It is not clear if this attribute is needed if there is a provider table that describes the type (basic, jwt, etc). This attribute is mostly used at application APIs when processing policy using an "implicit" provider by just looking at the JWT assertion or IP address (subtype is net).

Note: for the purposes of this discussion an "implicit" provider is defining a policy that looks strictly at inflight request data such as IP Address, JWT value, etc. The following providers are considered implicit: any, auth, jwt, saml, and net.

Describe the change you would like to propose
Should all subject types be listed in the providers table (eliminating the need for subType)?

What do you feel is the ideal solution?
The trade off is that for each IP address you want in a policy, you would have to define a new provider entry. This makes sense for providers like OpenID Providers which get re-used in many policies. However for implicit providers like 'net' it may be simpler because each IDQL policy can have a different IP address/mask.

What would be a minimal or good enough solution if any?
To be explored. There may be some advantage from a change management perspective to list implicit providers in the providers asset information. If internal addressing changes, then the provider ip address changes thereby updating multiple dependent policies.

Additional context

Section 4.4 action has inconsistent URIs

Please provide some basic information describing your suggestion
In the example, the first action is
https:POST:/Users/
Then the second action is:
ietf:https:PUT|PATCH:/Users/
Describe the change you would like to propose
Review the document and provide consistency. For HTTP and other RFC protocols, use ietf prefix. For app specific "roles" that map internally to an API function, use api: as the prefix. For platform, use platform specific roles (e.g. arn for AWS).

What do you feel is the ideal solution?

What would be a minimal or good enough solution if any?

Additional context

Use a $schema instead of type in Object Schema

*Please provide some basic information describing your suggestion
In 3.2, provider data is described where each JSON structure lists a "type" in the form .. Should we be using self-describing discovery schemas like JSON-Schema and/or JSON-LD?

Describe the change you would like to propose
In the current spec, we use JSON Schema because it allows the ability to say what attributes are needed in what combinations. JSON-LD handles referential information but does not describe more complete sets of attributes (e.g. attribute a requires b or c).

We could adopt a form:
{
"id": "CanaryProfileService",
"$schema": "https://config.example.com/schema/canaryapi.schema",
"subscription": "s1234567890",
"resourceGroup": "xyz",
"api-id": "8763f1c4-0000-0000-0000-158e9ef97d6a",
"location": "us-east-1",
"stage-name": "",
"resoource": "/Profile/*"
}

Where $schema points to the JSON-Schema format of the current Asset that describes the current set of claims of the object.

What do you feel is the ideal solution?
This likely depends on how the open source API Gateway evolves.

What would be a minimal or good enough solution if any?
TB discussed

Additional context

Should Section 4.3.1 JWT claims be moved out of IDQL to Providers Documentation

*Please provide some basic information describing your suggestion
Section 4.3.1 describes claims typically available when using the JWT provider subType. If Issue #1 is decided to move subType out then 4.3.1 should also be moved.

Describe the change you would like to propose

What do you feel is the ideal solution?
Move 4.3.1 to providers documentation.

What would be a minimal or good enough solution if any?

Additional context

Clarify difference between object and actions

*Please provide some basic information describing your suggestion
An object identifies a protected resource while actions identify the permitted or excluded actions against that object.

Objects should be singular while actions may be plural.

The path in an object is intended to be an overall constraining filter for all actions. An action path should also be a valid object resource path.

Actions do not need to be paths they can simply be rights that the subject must have to invoke a particular API endpoint

Remove Subject Type = "net" in and replace with "cidr" attribute on all subject types.

*Please provide some basic information describing your suggestion
In the current spec, only one subject type is allowed at a time. This means you can't restricted an authenticated subject type to a specific group of network addresses. It would be better to make the cidr attribute part of all subject types. This means you can match on just cidr by using type=anyAuthenticated or type=any depending on whether clients still need to be authenticated or not.

Discuss Embedding Configuration in Subject Definition vs Using ProviderId

*Please provide some basic information describing your suggestion
The current spec presumes an external configuration control system the holds the inventory of assets etc. Without this system being available, it is difficult to build the HexaPrototype.

Suggestion is to allow for "config" information to be added to the subject provider. For example, for OAuth issued tokens config could express properties such as "iss" and "aud".

Note: Iss and Aud should both be multiple in case multiple poviders or relying parties are represented by the same policy.

Policy owner definition - core specification

There is no reference in a policy definition for the owner of a policy. It's not clear to me in the schema how that would be defined, and yet this is a core capability of any policy engine.

In thinking about this from a migration perspective, one would need to export the definition somehow from the source system. If the response is that ownership of a policy is a policy itself, there should still be a way to reference the policy container.

I suggest making a condition of the policy exist for ownership as well as execution of the policy.

If this is considered in the specification, then an example would be valuable.

Revise Input Variables Per New opaTools Module

*Please provide some basic information describing your suggestion
Opa Tools provides some more contextual information such as JWT processing

Change Type "jwt" to "Bearer+Jwt"

*Please provide some basic information describing your suggestion
At present most JWT tokens are presented as "bearer" tokens. However, the IETF OAuthWG is finalizing DPOP tokens which may change the policy requirements going forward. When this happens, IDQL should be amended to support policy for DPOP using a different type.

Note: This item is intended mainly for discussion/tracking purposes. The issue of different JWT mechanisms may not turn out to be an issue from a policy perspective. Only the validation changes.

Section 4.6 Scope Multi-value

*Please provide some basic information describing your suggestion
In section 4.6, scopes are expressed as a variable assignment with a single value that can be used in expressions. Should multi-values be supported?

Describe the change you would like to propose
Multi-values MAY mean more complex specifications such as in conditions which use variables in matching expressions. In theory this is already supported.

What do you feel is the ideal solution?

What would be a minimal or good enough solution if any?

Additional context