Opaque Resource Identifiers (ORIs) with a hashed composite structure increase the abstraction level, offering a unified and secure method to manage resource identifiers across multiple backend systems. This pattern encodes a three-part composite identifier into a hash, enhancing security and obscuring the internal structure from the client.

Details

The hashed composite identifier structure consists of three main components that are concatenated and then hashed: the tenant or system identifier, the resource type, and the resource ID. This process helps in maintaining a uniform way to reference resources across different systems while ensuring the identifiers are opaque.

  • Tenant or System Identifier: Defines the originating system or tenant, crucial for routing and managing data in multi-tenant environments.
  • Resource Type: Clarifies the type of the resource, which aids in type-specific processing and validation.
  • Resource ID: A unique identifier for the resource within the specified system or tenant.

Once these components are concatenated (e.g., tenant,resourceType,resourceId), they are hashed using a cryptographic hash function to produce the opaque identifier. This hash conceals the composite structure from the client, adding an extra layer of security and data integrity.

Common Pattern Names/Synonyms

  • Hashed Composite Resource Identifiers
  • Secure Unified Resource Identifiers
  • Encoded Multi-part Resource Identifiers

Common Use Cases

  1. Security Enhancement: By hashing the identifiers, sensitive details about the backend architecture or data storage are obscured, mitigating the risk of security breaches.
  2. API Simplification: Maintains a consistent and straightforward API interface, even in complex systems with multiple data sources, such as after mergers or acquisitions.
  3. Resource Referencing Across Systems: Allows for uniform referencing of resources across different systems without revealing internal identifiers or structure.

Mermaid Sequence Diagrams

sequenceDiagram
    participant Client
    participant API_Gateway
    participant System_A
    participant System_B

    Note over Client, System_B: Client makes a request using the hashed ORI

    Client->>API_Gateway: GET /resources/eb2f7cf314
    Note over API_Gateway: Decrypts hash to determine routing
    alt Decrypted Identifier is "001,User,12345"
        API_Gateway->>System_A: GET /User/12345
        System_A-->>API_Gateway: Resource Details
    else Decrypted Identifier is "002,User,12345"
        API_Gateway->>System_B: GET /User/12345
        System_B-->>API_Gateway: Resource Details
    end
    API_Gateway-->>Client: Resource Details

Examples

  • Example 1: Hashed Identifier for Resource Fetch
    • Request: GET /resource/eb2f7cf314
    • Interpretation: Fetch a resource using the hashed identifier, which internally maps to, e.g., 001,Product,9876.
    • The API Gateway decrypts the hash to route the request to the correct backend system.
  • Example 2: Secure Cross-System Resource Access
    • Request: GET /resource/a1c2e33f47
    • Interpretation: Retrieve a resource using another hashed identifier, representing 002,Order,5555.
    • Enhances security by preventing the exposure of backend details through resource identifiers.

Implementation Tips

  • Use a strong cryptographic hash function to ensure the security and integrity of the identifiers.
  • Implement a secure mapping and decryption mechanism at the API gateway to correctly parse and route based on the decrypted identifiers.
  • Regularly review and update the hashing and decryption mechanisms to adapt to new security challenges.

Updated: