Anonymous Access

DirX Access facilitates two basic concepts of security: authentication and authorization.

  • Authentication within the DXA scope is a process at the end of which DXA knows the identity of a subject it communicates with.

  • Authorization within the DXA scope is a process at the end of which DXA decides whether certain subject (requestor) has the permission to perform certain operation (action on top of given resource supposing certain conditions).

While the authentication process can be requested on its own, e.g., retrieving an identity without additional authorization evaluation, the authorization can’t be utilized without preceding authentication. Simply speaking, we always have to know who is asking to be able to evaluate if they have the appropriate permission. There is, however, a specific situation in which we don’t need to know the full identity, but just some of its features. Moreover, there is a specific situation in which the feature sufficient for the authorization evaluation is the fact the requestor remains anonymous to us.

Anonymous Subject Representation

From DirX Access perspective, the requestor has to be authenticated for the authorization process to be applicable, but DirX Access also enables to authenticate it only to the point that the authenticated subject is “someone anonymous”. Internally, this is represented by a subject having no authentication principal (no authentication method used, no authentication time, etc.) but having an assigned role: Anonymous.

As the subject exists internally, it can be used in the Request injection process (with values expected according to the description in previous paragraph).

The anonymous subject is a single-request-only entity. This means it is never represented by any session (cookie, JWT, etc.) and any internal state isn’t preserved across multiple requests.

Authorization

The anonymous access is designed in alignment to the most native authorization way of DirX Access - the role-based access control (RBAC). RBAC binds the authorization evaluations at the highest level to the role of the requestor. Here, the Anonymous role can be used.

Compare this to the “Exclude from authorization” feature of any DXA Web Application. While the exclusion from web application lets the request at corresponding web application to bypass any authentication or authorization, the Anonymous Access first resolves if, for given resource, there’s actually no authentication method necessary, and if not, the anonymous subject is created and authorization policies declared for Anonymous role are examined.

Use Cases

  • Limiting access to resources based on contextual information

    • E.g., when an administrator wants to allow a native self-registration of new company employees, but wants to limit it by some physical conditional, such as being able to register only from company network and within working hours. Risk conditions can be used for the Anonymous role to achieve that.

  • Fine-grained authorization

    • E.g., during self-registration, DXA creates for the new user a completely new record. This record can contain information about roles, groups, etc. However, the administrator wants this information not to be manageable by the newly registered user. Hence, the authorization policies for role Anonymous can be set up in the way, that only subset of the parameters of the record are editable.

Configuration

The Anonymous Access feature is by default disabled (which helps to achieve backwards compatibility) and can be enabled by enabling the Cluster | Authentication Service | Enable anonymous subject configuration parameter.

The anonymous subject is resolved only in the situation the original request contains no session yet, and it also doesn’t map to any authentication method. Binding a request to authentication method is done typically via:

  • explicit listing of the intended authentication method within the request itself,

  • configuring authentication policies for requested resource,

  • configuring default authentication method for corresponding PEP.

Too broad authentication policies

If the existing authentication policies are too broad and anonymous access needs to be configured within their scope, the authentication method mapping can be inverted by specifying an authentication policy for anonymous access resources with no authentication method.

Anonymous Access with sessionless SSO

If Anonymous Access is configured together with sessionless SSO, an explicit authentication policy must be configured with an OAuth authentication method to be used when requesting an OAuth Authorization server.