Anonymous Access

It is often desirable for some requests to be permitted anonymously.

For example, on a FHIR endpoint that is SMART on FHIR enabled, the CapabilityStatement (/metadata endpoint) should be left unsecured. Some clients read the CapabilityStatement before they hold an access token, a secured /metadata endpoint would reject them before they can authenticate.

In order to enable anonymous requests on a FHIR endpoint, the Allow Anonymous Access property should be enabled on the endpoint configuration.

When this setting is enabled, any requests that do not supply any credentials will be granted the authorities of the designated Anonymous user. By default this is a user with the username "ANONYMOUS", but this can be modified using the Anonymous Account Username setting.

The Anonymous User

It is important to realize that the Anonymous user is a user like any other user, although it will typically (but not necessarily) have fewer permissions than a normal user. Anonymous users must be granted the ROLE_ANONYMOUS permission in order to distinguish them from regular users.

As an example, you might grant the anonymous user the FHIR_CAPABILITIES permission so that unauthenticated users can access the FHIR endpoint CapabilityStatement (i.e. the metadata operation) but not grant any other permissions. FHIR_CAPABILITIES is sufficient on its own: it implies ROLE_FHIR_CLIENT, which does not need to be granted separately.

This user must be declared in an Inbound Security Module that is configured as a dependency of the endpoint module being secured.

There are several ways of doing this:

• You can use an Inbound Security module such as the Local Inbound Security as the Username/Password Authentication dependency on your endpoint module. In this case, your anonymous user will be loaded from that module and the appropriate permissions applied to each request.
• You can declare an Anonymous Authentication dependency, in which case anonymous requests will be routed to the given module but other requests will not. This is useful for configurations where the anonymous user can not be supplied by the primary authentication module (for example, if it is an SMART Inbound Security module, or a Script Inbound Security module.)

Multiple Anonymous Accounts

If you have multiple endpoints that should have different anonymous behaviour, it can be useful to create a dedicated anonymous account for this endpoint.

To create a dedicated anonymous account, use the user manager to create a new account. This account must be granted the ROLE_ANONYMOUS role.

Callback Scripts

Anonymous Access

Security

Authentication Protocols Authorization and Consent Inbound Security Module Local Inbound Security Module LDAP Inbound Security Module Scripted Inbound Security Module SAML Inbound Security Module Trusted Client Mode Roles and Permissions Callback Scripts Anonymous Access Consent Service Consent Service: JavaScript API Consent Service: Java API Security Recipes Two Factor Authentication Password Hashing Algorithms JWT Signature Algorithms Troubleshooting Security

Consent Service