Security Overview
Introduction
RESTHeart provides Authentication and Authorization services. It can handle different authentication and authorization schemes, including handling users and permissions stored in MongoDB collections.
The default configuration file enables mongoRealmAuthenticator
and mongoAclAuthorizer
. These use MongoDB collections (by default /users
and /acl
respectively) to handle users credentials and permissions respectively.
RESTHeart can also handle users and permissions stored on configuration files via fileRealmAuthenticator
and fileAclAuthorizer
. Enabling these plugins requires updating the configuration.
Watch Authentication and Authorization in RESTHeart
Understanding RESTHeart security
RESTHeart is built around a pluggable architecture. It comes with a strong security implementation but you can extend it by implementing plugins.
In RESTHeart everything is a plugin including Authentication Mechanisms, Authenticators, Authorizers, Token Managers and Services.
Different Authentication Mechanisms manage different authentication schemes. An example is BasicAuthMechanism that handles the Basic Authentication scheme. It extracts the credentials from a request header and passes them to the an Authenticator for verification.
A different example is the IdentityAuthMechanism that binds the request to a single identity specified by configuration. This Authentication Mechanism does not require an Authenticator to build the account.
RESTHeart allows defining several mechanism. As an in-bound request is received, the authenticate()
method is called on each mechanism in turn until one of the following occurs:
- A mechanism successfully authenticates the incoming request → the request proceeds to Authorization phase;
- The list of mechanisms is exhausted → the request fails with code
401 Unauthorized
.
The Authenticator verifies the credentials extracted from the request by Authentication Mechanism. For instance, the BasicAuthMechanism extracts the credentials from the request in the form of id and password. The Authenticator can check these credentials against a database or a LDAP server. Note that some Authentication Mechanisms don’t actually rely on a Authenticator to build the Account.
The Authorizer is responsible of checking if the user can actually perform the request against an Access Control List. For instance the RequestPredicatesAuthorizer checks if the request is allowed by looking at the role based permissions defined using the undertow predicate definition language.
The Token Manager is responsible of generating and validating an auth-token. When a client successfully authenticates, the Token Manager generates an auth-token that is returned in the Auth-Token
response header. It can be used to authenticate further requests. This requires an Authentication Manager to handle it using the Token Manager for token validation.
A Service is a quick way of implementing Web Services to expose additional custom logic.