Support using session-credential in notification logon
andy-maier opened this issue · 2 comments
When MFA is enabled, the authentication to the JMS notification service of the HMC no longer works with the user's password, but requires the session-credential returned by the HMC logon operation.
The zhmcclient library is not storing the session-credential at the moment and thus has no means to use it when authenticating to the JMS notification service.
This issue is to store the session-credential in the zhmcclient.Session object and to use it when authenticating with the JMS notification service.
It needs to be investigated whether the session-credential can be used always, or only when MFA is enabled.
Note also the recent PR #1346 which addresses some of that.
I don't have an HMC access without MFA to check this. I'm sorry.
I thought the field was returned always. HMC API docs 2.26:
The session-specific authentication credential for this session. This token can be used to connect to the API message broker on behalf of the HMC user associated with this session. See “Connecting to the APImessage broker” on page 74 for more information.
However, I understand your concern because under section "Connecting to the API message broker":
The listening ports for the message broker are fixed port numbers and are not subject to customer
reconfiguration. Thus, client applications can treat them as well-known port numbers rather than
requiring customer input when configuring the networking parameters the client will use to connect to the
HMC.
In order to connect to the integrated message broker, clients must provide certain authentication
information for the HMC user making the connection. If the HMC user is configured to use multi-factor
authentication, then the client must provide information about the HMC user's API session that is to be
associated with the message broker connection. The user name field in the connection request must
contain the API session ID, and the password field must contain the session-specific authentication
credential. Both of these are available in the response body of the Logon operation that created the API
session: the api-session and session-credential fields, respectively.
If the HMC user is not configured to use multi-factor authentication, then the client may provide the
authentication information as described immediately above, or it may provide a valid HMC user name and
logon password in order to identify the HMC user making the connection. The user name and password
are validated using the standard HMC user authentication mechanisms before allowing the connection to
succeed.
The integrated message broker does not allow any anonymous or unauthenticated connections.
With PR #1346 being merged, the only remaining piece of work is to use the session-credential for logging on to the notification service. It seems the session-credential can be used in both cases, with and without MFA enabled.