Access control for APIs

APIs can be configured to enable read or write access to content managed on the Lobster Data Platform or to control workflows that, through integration, may also involve connected third-party systems..

Regardless of the intended use and characteristics of an interface (e.g. REST API vs. MCP Server) security considerations should play a key role in its design and implementation.

Access control for endpoints of a REST API or tools provided by a MCP Server can be managed at the following levels:

• Total URL requests to Lobster Data Platform.

  • Who can actually access the platform via its URL?

• Activation status of the API configuration (see API Manager):

  • An API must be set to "active" (enabled); otherwise, the configurations for all included endpoints or tools are completely ineffective.

  • If no active API contains a definition for a specified endpoint or a tool, an HTML error (404: Not found) occurs.

• Mandatory authentication per endpoint or tool:

  • For each endpoint or tool definition, the "Anonymous access" flag (allowAnonymousAccess) determines whether access without authentication is generally permitted (true) or not (false).

  • An anonymous attempt to access an endpoint for which the "Anonymous access" flag (allowAnonymousAccess) is not set fails with an HTML error (401 Error: Unauthorized) and the Lobster Data Platform error code CORESYSTEM_AuthenticationManager_401 in the response body.

• Optional: Assign Association criteria per API and/or endpoint or tool:

  • Access to an API, endpoint, or tool can be contingent upon the assignment of Association criteria to the fulfillment of additional, arbitrarily complex validation criteria.

  • The validation logic can include all Rule types.

    • For authenticated access, the following rule types from the Session based category are particularly important:

      • Role rule, User rule, Company rule, Company type rule

    • For anonymous accesses, when assigning Association criteria, it must be taken into account that due to the lack of a session context (no Company of session as a reference point for ownership restrictions or Company authorizations), they are only considered context-relevant if no owner is assigned to them. This generally applies to predefined assignment criteria in the system ("Assign to...").

  • As is typical with associations, if multiple Association criteria are assigned in parallel, at least one must be met for a configuration to be considered "associated" in context. Access to REST API endpoints or MCP server tools is therefore restricted based on assignments only if ALL assigned Association criteria are EITHER considered not met OR are not relevant due to ownership restrictions in the execution context. In each of these cases, the HTML error in the response (403 Error: Forbidden) indicates that the request reached the API but was denied. The response body returns the Lobster Data Platform error code CORESYSTEM_AuthenticationManager_403.

Choose between competing endpoint/tool definitions

Technically, it is not impossible for different API configurations to provide definitions for the same effective endpoint/tool address.

When a call is made at runtime, a set of criteria is evaluated hierarchically if there are multiple "candidates" that could serve as the destination.

• When calling REST API, the HTTP method used must match the selection in the endpoint configuration.

  • If "candidates" are identified but none of them meet this criterion, an HTML error (405: Method not allowed) occurs. Any additional criteria are then irrelevant.

• If the request is made "anonymously" (without a login context), only "candidates" that allow "anonymous access" are eligible (see above: "Authentication requirement").

• If multiple "candidates" meet the relevant conditions, the priority of the parent API configuration is taken into account (see API Manager).

• The assignment of Association criteria (per API or endpoint) does not affect the selection decision. Such criteria are evaluated only after a decision has been made.

  • It is therefore possible that a "candidate" from a high-priority API, for which all assigned Association criteria in the call context are not applicable, "intercepts" a call (with HTML error 403 Error: Forbidden), for which a lower-priority competitor without a binding to Association criteria (or with one criterion met) would have been a qualified recipient in that context.

 WARNING The following applies to APIs, endpoints, and tools:  EXCEPTION  NO assignment = NO access restriction

Normally, configurations to which Association criteria can be assigned are inoperable as long as no assignment has been made.

In contrast, within an API configuration, the following applies: As long as Association criteria is not assigned at all for a given level (API vs. endpoint/tool), unrestricted access is granted.

• API configurations created before the introduction of access control using Association criteria therefore remain accessible without the need for explicit assignments.

• However, in this particular case, removing all mappings within an API configuration does not prevent access to the relevant endpoints.