J2ee security can be implemented either as declarative (i.e. entirely in configuration files) or programmatic (i.e. implemented in code, using the Sun API's). Declarative is recommended.

Concepts

Subject - defined by JAAS as "any user of a computing service." Maps roughly onto Martin Fowler's idea of a "party."

Principal - an entity that can be authenticated, in fact a name that a Subject uses to interact with a service. Each user of the system will typically have a set of Principals which they use to interact with the system. A principal has a Principal Name and Authentication Data.

Credentials - data or attributes used to authenticate a Principal. Sun doesn't define any specific class to represent credentials, coders can use any object they want.

Realm - a set of security policies. Users belong to one realm. The default realm always exists.

Group - a user can be a part of a J2EE group. A J2EE group's scope is the entire J2EE environment.

Security Role - similar to a group, but scope is only within a single application. Roles are declared in the ear file. Each Principal is mapped into one or more roles.

There are two approaches to authorization: capabilities and permissions. Capabilities are user-oriented, i.e. the user can do this or that but not the other. Permissions work the other way. i.e. for this method on this EJB, only these roles can call it.

Servlet

Servlet security can be declarative (in web.xml) or procedural. For procedural security see HttpServletRequest, especially the getUserPrincipal() and isUserInRole() methods here.

EJB

EJB security can be declarative (in ejb-jar.xml) or procedural. For procedural security see EJBContext, especially the getCallerPrincipal() and isCallerInRole() methods here.