Is your feature request related to a problem? Please describe.

When creating policies, users might need access to token entities. For instance, a token entity could be referenced in the attributes of a principal entity. Here's an example of how this might look in a schema:

namespace Jans {
    entity Access_token = {
        jti: String,
    };
    entity Custom_token = {
        jti: String,
    };
    entity Workload = {
        client_id: String,
        access_token: Access_token,
        custom_token: Custom_token,
    };
}

To streamline this process, we aim to automate the creation of these token entities and ensure they are properly referenced within principal entities. However, this requires a mechanism to link token entities to their corresponding principals during entity creation.

Furthermore, we want this solution to support any custom tokens that the user might want.

Describe the solution you'd like

Supporting custom tokens

Currently, input tokens are passed into Cedarling using a map:

input = { 
           "tokens": {
               "access_token": "...", 
               "id_token": "...", 
               "userinfo_token": "...", 
               "custom_token": "..." 
            },
           "resource": {"id": "12345", "type": "Ticket", "creator": "mike@gluu.org", "organization": "gluu"},
           "action": "View",
           "context": {
                       "ip_address": "54.9.21.201",
                       "network_type": "VPN",
                       "user_agent": "Chrome 125.0.6422.77 (Official Build) (arm64)",
                       "time": "1719266610.98636",
                      }
         }

decision_result = authz(input)

Token Name -> Entity Name mapping

We know that the access_token, id_token, and userinfo_token are token entities because of the CEDARLING_MAPPING_ID_TOKEN, CEDARLING_MAPPING_ACCESS_TOKEN, CEDARLING_MAPPING_USERINFO_TOKEN bootstrap entities. However, we might need more than these to support custom tokens.

Instead of separate boostrap property for each token, we can use a single object to hold all token to entity name mapping.

CEDARLING_MAPPING_TOKEN_ENTITIES = {
    "access_token": "Jans::Access_token",
    "id_token": "Jans::id_token",
    "userinfo_token": "Jans::Userinfo_token",
    "custom_token": "SomeCompany::Custom_token"
}

Token Entity -> Principal Entity mapping

To support putting custom tokens into principal entities, we can introduce a bootstrap property called CEDARLING_TOKEN_PRINCIPAL_MAPPER which is a map of token identifier -> fully qualified token entity name. for example:

CEDARLING_TOKEN_PRINCIPAL_MAPPER = {
    "access_token": "Jans::Workload", 
    "id_token": "Jans::User", 
    "userinfo_token": "Jans::User", 
    "custom_token", "Jans::Workload"
}

Automatically adding token entities to the principal entity's attributes

To automatically add token entities to the principal entity's attributes, we can employ the following approach:

1. Create Token Entities: Begin by creating the required token entities.
2. Store Entity References: Save the unique IDs of the created token entities for later use.
3. Create Principal Entities: When creating a principal entity, check if its schema requires references to token entities.
   • If required token entities already exist, use their IDs to establish the reference.
   • If a required token entity is missing, fail the creation of the principal entity and log the issue.

In this approach utilize the already existing Cedar schema together with the CEDARLING_TOKEN_ENTITY_MAPPER bootstrap property to:

1. Know which entities in the schema are token entities
2. Know which principal entities require token entities
3. Automatically insert token entities into the principal entity attributes if it's specified in the schema

Describe alternatives you've considered

N/A

Additional context

This feature would make token handling in Cedarling more customizable and applicable to a broader range of scenarios, including systems with non-standard or custom token usage.