Security
Subject
Each user in the system is assigned a Subject (RHQ_SUBJECT is the DB table). The user is typically authenticated by RHQ via the JDBCLoginModule. You can use LDAP for authentication, in which case LdapLoginModule will be invoked that performs the check against the configured LDAP server, but it only does authentication checks. Authorization is performed by roles created in the RHQ database. For this reason, even users that are authenticated via LDAP will still have a Subject entity associated with him. The difference is that a LDAP user will not have a Principal entity but users that are authenticated by RHQ will have an associated Principal object.
Web Clients
The JAAS module (JDBCLoginModule or LDAPLoginModule) is responsible for actually authenticating the user against the appropriate backend.
The J2EE "/j_security_check" redirects to AuthenticateUserAction which has the responsibility of logging the user into the RHQ system. This class does several things. The first is that it gets the user his RHQ session, which is different than the HTTP session the web container assigns the user. It will also set up the user's HTTP session witih information the core UI needs (like user preferences). This action also redirects the user to the self-service LDAP registration form when appropriate. This LDAP registration form allows the user to create his own Subject based on his LDAP identity (this LDAP form will only be seen by users that are authenticated by LDAP).
Finally there is AuthenticationFilter which is used to make sure users are logged in and their session is still valid when going to any URL (in the case of a bookmarked URL, this ensures the user is logged in; if not, the request is redirected to the login page).
Remote Clients
Remote clients that call into the remote EJB interface or the Web Service API must first obtain a Subject for the client's identity. They do this by directly logging into the system via SubjectManager's login method. Once a subject is obtained, it is considered logged into the RHQ system. That subject is passed explicitly to the remote API.
Server-side code then utilizes either direct authorization checks (see AuthorizationManagerBean) or they rely on RHQ's built-in security interceptor (RequiredPermissionsInterceptor) to check that the passed-in subject has the appropriate permissions. That interceptor examines the invoked method and checks any permissions it requires - which is defined if they are annnotated with either RequiredPermission or RequiredPermissions.