Want to learn more about securing a REST service? Check out this post where we look in-depth at securing your REST service on different platforms.
If you’re building a REST service, then that REST service will expose some kind of data or will allow some kind of interactions with a server. For instance, consider a Facebook REST service that allows you to retrieve your chat history. Naturally, you don’t want just anyone looking at that history, hence the need for security.
What Are the Concepts Involved With REST Service Security?
For Java EE security, there are a few basic concepts involved:
- Caller — A user or script that calls the REST Service.
- Role — An opaque attribute or ID associated with a specific caller. This is used to refer to a group of callers in an abstract way. For example, “all callers with the role ‘xyz.'”
- Authenticating — Callers proving their identity, largely synonymous to “logging in.” For example, “Is the caller claiming to be Sarah indeed Sarah?”
- Authorizing — Determining whether a caller has access to something. For example, “Is Sarah allowed to see Mike’s photos?”
- Authentication Mechanism — This refers to the specific way in which the server interacts with the caller to authenticate that caller. For example, with the BASIC authentication mechanism, a caller sends a username/password combination via an HTTP header, but with the JWT authentication mechanism, a JWT token is sent.
- Identity Store — A logical unit that is capable of validating credentials and returning a caller name and zero or more roles associated with that caller. Often, but not necessarily, the identity store provides access to (external) storage containing the details of callers, their credentials, and their roles, for example, a database, file, or LDAP identity store. All this data can also be stored within the effective credential, which is the case for a JWT token.
How to Secure a REST Service
For Java EE Security/the Payara Platform, there are a couple of options:
- REST Services can be secured by defining constraints on the URL, endpoint (resource class), or method level.
- An authentication mechanism can be chosen from those defined by the Servlet API, by the Java EE Security API, or a custom (application provided) one can be used.
- An identity store can be left undefined by the application and left to be configured within Payara Server (for example, using the admin console or CLI), one can be chosen from those defined by the Java EE Security API, or a custom (application provided) one can be used.
Which Authentication Mechanisms Are Available in the Payara Platform?
The Payara Platform ships with the authentication mechanisms defined by the Servlet-, Java EE Security-, MicroProfile- and Payara APIs. These all can be used largely interchangeably. Note that not all of them are primarily useful for REST authentication, but are instead more suited for interactive websites (specifically the FORM based ones).
Servlet
BASIC
FORM
DIGEST
CERTIFICATE
Java EE Security
BASIC
FORM
Custom FORM
MicroProfile
JWT
Payara API
OAuth2
OpenID Connect (coming in 5.183)
Yubikey
Which Identity Stores Are Available in the Payara Platform?
The Payara Platform ships with the identity stores defined by the Java EE Security API and its own internal ones (a JAAS LoginModule/GlassFish Realm combination) that can be configured via the admin console, CLI, or domain.xml. In Payara 5.182 and before identity stores from Java EE Security, we can be paired with authentication mechanisms from Java EE Security, MicroProfile, and the Payara API, but not with those from Servlet. Likewise, the internal ones can only be paired with the authentication mechanisms from Servlet. Payara 5.182 will likely make these all interchangeable. Note that MicroProfile JWT has its own identity store, but it can be paired if needed with additional identity stores if extra roles beyond those provided by the JWT token are needed.
Java EE Security
LDAP
DataBase
Payara Internal
File
LDAP
JDBC (DataBase)
Digest
Solaris
