The article covers authentication and authorization.
See also Java EE 6 Tutorial
Getting the context of the current call can be achieved with the
@Context private HttpContext context;
In Basic Auth a Http Header is added to the HTTP request.
Authorization: Basic <user>:<pass>
The credentials need to be Base64 encrypted.
In the web.xml file the authentication type must be set.
<login-config> <auth-method>BASIC</auth-method> <realm-name>jdbcrealm</realm-name> </login-config>
Specifying a combination of URL patterns, HTTP methods, roles and transport constraints can be daunting to a programmer or administrator. It is important to realize that any combination that was intended to be secure but was not specified via security constraints, will mean that the web container will allow those requests. Security Constraints consist of Web Resource Collections (URL patterns, HTTP methods), Authorization Constraint (role names) and User Data Constraints (whether the web request needs to be received over a protected transport such as TLS).
If no auth-constraints are placed in the web.xml then no authentication will be made, means any normal user and anonymous users can use the service.
<role-name>*</role-name> accepts any authenticated user but denies access for anonymous users.
Roles used in the application must be declared either by annotations (@DeclareRoles) or per web.xml entries (secuity-role).
<web-page> ... <security-role> <role-name>admin</role-name> </security-role> <security-role> <role-name>superuser</role-name> </security-role> <security-role> <role-name>user</role-name> </security-role> ... </web-app>
See Java EE 6 Tutorial - Declaring Security Roles.
isUserInRole(role)will always return
Java EE does not specify a single component/way to check if a the authenticated user is in a specified role.
|Component||API used to check role|
From: IBM Information Center Using annotations to secure Java EE applications
Roles can be mapped from roles names used in the application to roles names used in the realm (f. e. database).
Theses mappings are container dependend. Glassfish stores these mappings in WEB-INF/glassfish-web.xml.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app error-url=""> <class-loader delegate="true"/> <jsp-config> <property name="keepgenerated" value="true"> <description>Keep a copy of the generated servlet class' java code.</description> </property> </jsp-config> <security-role-mapping> <role-name>admin</role-name> <group-name>admin</group-name> </security-role-mapping> <security-role-mapping> <role-name>superuser</role-name> <group-name>superuser</group-name> </security-role-mapping> <security-role-mapping> <role-name>user</role-name> <group-name>user</group-name> </security-role-mapping> </glassfish-web-app>
Glassfish needs explicitly a mapping for each used role name. Other application servers may behave differently and may assume that the names are identical if not stated otherwise.