JBoss Community Archive (Read Only)

RHQ 4.9

Perspective Context

Perspective Context

When the user navigates to an extension, that extension may likely call out to a perspective application (PA) for content. To deliver that content, the PA may need various contextual data supplied from the RHQ Server.

The necessary context will be supplied as request parameters of the PA HTTP request.

Single Sign ON (SSO)

To discuss SSO, we'll break it into two parts: SSO for Remote API Login and SSO for External Application Login.

SSO for Remote API Login

In most cases, the PA will need to interact with the RHQ Server to generate the content for the perspective request. To do this, it will use the RHQ Remote API. Remote API calls require a valid Subject (org.rhq.core.domain.auth.Subject) to be supplied with each call. The Subject represents an active RHQ Session for a defined, logged in RHQ user.

The PA will be provided the rhqSessionId as a request parameter. The workflow will look like this:


Note, the diagram shows the general flow but not all of the current steps. See details below.

Stepwise the flow is:

  1. User logs into RHQ

  2. User navigates to Perspective P's extension that has a url set for PA.

  3. RHQ GUI requests content from PA, passing server info and the user's rhqUsername and rhqSessionId as request parameters.

  4. PA established a RemoteClient connection with the provided server info

  5. PA then calls the remote API to retrieve the associated Subject via the rhqUsername and rhqSessionId.

    • note1: SubjectManager.getSubjectByNameAndSessionId(rhqUsername, rhqSessionId) is a newly exposed remoteAPI call.

      • for perspective apps deployed to RHQ Server we'll (probably) set the host to automatically

      • depending on the defined transport I think we can determine whether to send the unsecure or secure port

  6. Using the retrieved Subject subsequent Remote API calls can be made.

  7. PA disconnects from the RemoteClient

This approach basically extends the user's current RHQ session to include the PA requests. The session used by the remote API is the same and subject to the same restrictions, same resource access, same user permissions, same session timeout etc.

To protect the rhqSessionId, a secure transport would need to be in use. Note that this is no more or less secure than RHQ's current design. It would be highly recommended that we change sessionId to a long, or uuid. Something more complex that can be passed as a request parameter and not easily generated.

SSO for External Application Login

This is a bit different. In this case we're talking about a perspective application that has its own authentication layer in place.

With regard to SSO, the perspective app's authorization must be utilizing a common SSO solution with RHQ. Meaning, there is no way to provide SSO with external apps that are using a foreign authorization mechanism. In that case, the login credentials must be provided or gathered by the PA, and the end user will probably need to provide them explicitly.

At this point, the design is fairly general and will need refinement.

For a cooperating application, the general idea is that the RHQ sessionId continues to be the proof of login. So, this is a progression of SSO for Remote API Login and assumes it is in place.

Given the Subject associated with the sessionId, one can determine the username. This username could then be used to assume valid login in the external application.

Username Mapping

One possible extension to RHQ would be a username mapping facilty, accessible by the security manager and configurable through the administration console of the RHQ GUI. Basically, tuples would be defined for <perspectiveApp, rhqUsername, appUsername>. So an rhqUsername (e.g. rhqadmin) can be mapped to a username (e.g. fooadmin) in the secured perspectiveApp. The remote API would be extended for this tuple management and therefore the external application login could be made for a user other than that provided in the RHQ Subject.

So, after the Subject was retrieved the external app, in the authorization logic, would perform steps like:

  1. localUsername = rhqAuthorizationManager.getMappedUsername(rhqSubject, rhqApplication)

  2. if happy with mapping
       auto-authenticate as localUsername and bypass login page
       login page
LDAP implications

Note that RHQ supports user authentication via external LDAP. In this situation, RHQ login could be presented with previously unknown, but valid, users. On their first login, they are initially directed to the user registration page and then allowed to continue. So, it could be quite difficult to know about all users in advance. So, it may be necessary for the external application to be able to handle an unknown username. Of course, the external application could just default to a login page in any situation outside the normal flow, and bypass SSO when it does not make sense.

A New Model?

As it stands now the user management in this external application SSO model is controlled by RHQ. And the trusted store would be the RHQ database. Although out of scope for this perspective design, it could be that a completely new SSO model is implemented such that RHQ and any cooperating apps are using a new, common, authorization scheme and trusted store. In such case the public API's already in place for RHQ probably need to be maintained and hopefully the Subject/sessionId design can be maintained. As such, it would be hopeful that those entities could still be used in some fashion to enable the external application SSO.

Navigation Context

Outside of SSO, the PA may need additional context to generate its content. The following request parameters will be provided when available:

Parameter Name



always provided, the RHQ Server public endpoint host


always provided, the RHQ Server public endpoint port


always provided, the logged in user's rhq username


always provided, the logged in user's rhq session id


always provided, the PA being called (i.e. self), as defined in the perspective descriptor


When the user has navigated to a specific resource


When the user has navigated to a specific resource group


When the user has navigated to a specific autogroup (may not be needed for current extensions points)


When the user has navigated to a specific autogroup (may not be needed for current extensions points)

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 08:13:50 UTC, last content change 2013-09-18 19:41:09 UTC.