Policy Language

Entrypage uses a special policy language to record policies. Entrypage policies are designed with the following philosophy in mind:

• Policies validate claims, either
  • Given claims are present
  • Given claims must match exact values
  • Given claims may not match exact values
  • Given claims must be at least X
  • Given claims must be at max X

Policies are a collection of rules that are applied to one or more clients. It’s important to note that policies cannot be applied domain-wide. You can configure policies either through the Entrypage API or within the Policies section of the management portal. To make a policy active, you must select and apply it to a client.

Policies are expressed in the following format:

policy:
  - id: policy.example
    description: "example"

    all:
      - rule:
          claim: "{claimType}"
          maxValue: "{example}"
          minValue: "{example}"
          in:
            - "{example}"
          not-in:
            - "{example}"

Each policy has a unique id and an optional description. A policy will contain either an all or an any section.

• all: This means every single rule defined within this section must be satisfied for the user to be granted access. Think of it as an “AND” condition.
• any: This means at least one of the rules defined within this section must be satisfied. This acts as an “OR” condition.

Policy Evaluation link

Policies are applied to Clients. A single Client can have multiple policies assigned. When this is the case, access is granted if at least one of the assigned policies is satisfied. This follows an implicit “OR” logic across policies.

If none of the assigned policies are satisfied, the user will be denied access and redirected to an “Access Denied” page. This event is recorded in the audit stream for further inspection.

Note: Policies are evaluated against the aggregated claims from both the ID token and the access token, after any configured claim mappings have been applied.

Deconstructing the rule link

Every rule must have a claim property. This property specifies which claim from the user’s profile we are inspecting. If the specified claim isn’t present, the rule is never satisfied.

Beyond the claim property, you can use other properties to define the rule’s conditions:

• minValue and maxValue: These properties define a numerical or temporal range for the claim’s value.

  • Numeric values: You can check if a claim value is greater than or less than a number. For example, a rule could check if a claim called creditScore has a minValue of 700.
  • Dates: You can compare a date claim (like birthdate) against a specific date. This is particularly useful for age verification.
  • Periods: To handle dynamic dates, such as checking if a user is “over 18 years old,” Entrypage supports ISO 8601 Periods.

• in: This property takes a list of values. The rule is satisfied if the claim’s value is present in this list. This is a simple way to check for multiple possible values without creating a complex set of “OR” rules.

• not-in: This is the opposite of in. The rule is satisfied if the claim’s value is not in the provided list.

Sure, here’s a much more concise, documentation-style explanation of Entrypage’s numerical policy rules.

Numerical and Temporal Policy Rules link

Entrypage policies use the minValue and maxValue properties to compare a user’s numerical claims against a specific range. The values for minValue and maxValue can be:

• A numeric value: Used for standard numerical comparisons (e.g., 1000).
• A date: For comparing against a specific date (e.g., 2025-01-01).
• A period: For dynamic date comparisons using the ISO 8601 format (e.g., P18Y for 18 years).

Examples link

1. Minimum Value Check link

This policy requires a user’s credit_score claim to be at least 700.

policy:
  - id: policy.min-credit-score
    description: "Requires a minimum credit score of 700."
    all:
      - rule:
          claim: "credit_score"
          minValue: 700

2. Value Range Check link

This policy requires a user’s loyalty_points claim to be between 1000 and 5000, inclusive.

policy:
  - id: policy.silver-tier-member
    description: "Access for members with 1000 to 5000 points."
    all:
      - rule:
          claim: "loyalty_points"
          minValue: 1000
          maxValue: 5000

3. Dynamic Date Check (Age Verification) link

This policy checks if a user is at least 18 years old. It uses an ISO 8601 period to dynamically calculate the required birthdate based on the current date.

policy:
  - id: policy.is-over-18
    description: "Requires the user to be at least 18 years old."
    all:
      - rule:
          claim: "birthdate"
          maxValue: "P18Y"

Periods link

To handle use cases like ensuring a user is over a certain age, Entrypage uses the maxValue property combined with an ISO 8601 Period. This allows for dynamic age checks without having to manually calculate a specific date in the past.

For instance, to check if a user is at least 18 years old, you would use a rule that looks at their birthdate claim and a maxValue of P18Y. This period represents “18 years.” Entrypage will dynamically calculate the current date minus 18 years and compare it to the user’s birthdate.

Telemetry link

Failed authorization requests are logged as information events in your Entrypage instance. Each log entry specifies which policy was not satisfied.

Requests may also be denied for other reasons, such as when:

• A user’s account is inactive.
• A user signs in with an authorization provider that is not enabled for the specific client they are trying to access.

Related documentation link

• Standard Claims