Relation Identifier Access Restriction

See the "User Access" chapter of the Security Guide for details of this type of access restriction. The HTTP API only exposes relation identifiers to which the user has access.

Restrict Top-Level Resource

Use Case

A relation identifier is retrieved as top-level resource.

The user can retrieve the restricted relation identifiers as normal, but the identifier attribute is concealed when the corresponding identifier type is access restricted.

Restrict Sub-Resource

Use Case

A top-level resource is retrieved with identifiers as its sub resource.

The HTTP API does not filter out the relation identifiers. Instead it conceals the identifier attribute on the relation identifiers that belongs to the identifier type to which the user does not have access.

Concealing of Linked Resource

The HTTP API does not support this case. Identifiers do not act as linked resources, they can only act as top-level or sub resources.

Inference Prevention

The HTTP Query API supports searching for persons or relations based on their identifiers:

POST http://[hostName]:[portNumber]/[api-context-root]/generic/persons/search

{
  "resource": {
    "q": "relationIdentifierList(+).identifier.eq('123-34-5456')"
  }
}

When a relation identifier is used for finding a person (and that person exists), but the identifier type of the matching relation identifier is restricted, then it is inferred that the person is not returned.

In other words, when searching for relations or persons based on a relation identifier, the query ignores relation identifiers that belong to an identifier type to which the user does not have access. The HTTP Query API automatically applies a filter when a relation identifier attribute is used as query condition.

This restriction does not apply when searching for relations or persons without any relation identifier search criteria.