if happy with mapping auto-authenticate as localUsername and bypass login page else login page
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:
-
User logs into RHQ
-
User navigates to Perspective P's extension that has a url set for PA.
-
RHQ GUI requests content from PA, passing server info and the user's rhqUsername and rhqSessionId as request parameters.
-
PA established a RemoteClient connection with the provided server info
-
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 127.0.0.1 automatically
-
depending on the defined transport I think we can determine whether to send the unsecure or secure port
-
-
-
Using the retrieved Subject subsequent Remote API calls can be made.
-
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:
-
localUsername = rhqAuthorizationManager.getMappedUsername(rhqSubject, rhqApplication)
-
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.