For an application to be secure, it must manage access to protected resources. Authorization determines which resources a user can access.

In applications where only certain users are entitled to access certain resources, users and groups are assigned roles that correspond to the resources that they can access. Authorization is the process by which an application determines a user’s role and the permissions that role includes. For example, in a payroll application, users in the Employee role can view a page that lists their hourly wages and hours worked. However, only users in the Manager role can edit employee wages. During authentication, Open Liberty identifies users and determines what access groups they belong to. When a user attempts to access a protected resource on the server, this information determines whether the user is authorized to access the resource.

Define roles in your application code

You can specify which roles can access an application resource by setting the @RolesAllowed annotation in the source code to contain the permissible roles, as shown in the following example:

@RolesAllowed({ "admin", "user" })

You can map the roles that are declared in the application to existing groups from a user registry or SSO identity provider. Specify the security-role element within the application-bnd element in the server.xml file, as shown in the following example:

   <security-role name="admin">
     <group name="Manager" />
     <group name="TeamLead" />
   <security-role name="user">
     <group name="Employee" />

The name attribute of the security-role element corresponds to a role that is specified in the application. The name attribute of the group elements correspond to the groups that are specified by a user registry or SSO identity provider. If the role names match the group names exactly, the server maps the group to the role with a matching name by default. If you use this default mapping, you do not need to specify an application-bnd element in the server.xml file.

In some cases, an application needs to know only the user’s authentication status. In such cases, you can specify ** as the role name in the @RolesAllowed annotation. This value denotes that any authenticated user can access a resource. Alternatively, you can authorize all users by setting the @PermitAll annotation, which specifies that anyone can access a resource, even users who are not authenticated.

Configure servlet security roles

The @RolesAllowed annotation typically specifies role-based access to back-end application resources, such as calls to a database. To control authorization for front-end resources, such as HTTP calls, you can specify roles in the servlet code by configuring the @ServletSecurity annotation. You can specify the permissible roles with rolesAllowed attribute on the @HttpConstraint or @HttpMethodConstraint parameters. The @HttpMethodConstraint parameter specifies constraints for specific HTTP methods. The @HttpConstraint parameter specifies the default constraints for all HTTP methods that are not otherwise specified by the @HttpMethodConstraint parameter.

In the following example, the @HttpConstraint parameter specifies that all HTTP methods are constrained either to the user role or the admin role. The @HttpMethodConstraint parameter specifies that the POST method is constrained only to users who are in the admin role:

@ServletSecurity (value = @HttpConstraint(rolesAllowed = { "user", "admin" }),
  httpMethodConstraints = {@HttpMethodConstraint(value = "POST", rolesAllowed = {"admin"})})

Authorize requests between web services

Authorization occurs not only between users and applications, but also between microservices within an application. When one service requests data from another, the requesting service often must demonstrate that it is authorized to access the data. Token-based authorization, such as with JSON Web Tokens (JWT), provides a lightweight way for security controls and security tokens to propagate user identities and roles across different services. Open Liberty supports token-based authorization through the MicroProfile JWT feature.

Configure authorization with a deployment descriptor file

Although annotations are the most common way to define roles in microservices, you can also define roles by specifying security-constraint elements in a web.xml deployment descriptor file. This configuration might be necessary in situations where you want to keep the security configuration separate from the development environment and apply it at deployment time.

Some applications rely on a combination of declarative annotations and a deployment descriptor file. In these cases, deployment descriptor values supersede annotations. Therefore, you can specify roles in a deployment descriptor file if you want to override security settings or defaults from elsewhere in the application code. For more information, see the Adding authentication and authorization section of the Securing a web application guide.