This mode is the same as wsman:secprofile/https/mutual except that an authorization header is used in addition to mutual authentication using the TLS 1.0 handshake.
This is used in cases where the mutual authentication is used at one level to ensure the two endpoints have authorization to communicate (such as machine-level certificates), but the resources may be secured at different levels, so an additional level of authorization has to occur using the HTTP authorization header:
Client Service
1 Client connects with cert and special auth header
Î Service queries for client cert and authenticates. If cert is missing or invalid, the sequence stops here with 403.7 or 403.16 return codes.
2 Í After authenticating the certificate, the service sends 401, listing
available auth modes (Digest, Basic, etc.)
3 Client selects new auth mode to use
Î Service authenticates the client again
In the initial request, the HTTP authorization header MUST be Authorization: wsman:auth/https/tls/1.0/rechallenge
This indicates to the service that this special mode is in use and it can query for the client certificate. The service then returns a 401, listing the authorization headers to use in subsequent requests.
If the initial certificate is not valid or missing, then 403.7 or 403.16 is returned as appropriate.
9.10
Subscriptions
When specifying the wse:NotifyTo address in subscriptions, it is often important to give hints to the service as to which authentication model to use when delivering the event. If no hints are present, then it is assumed that the service can simply infer from the wsa:To address what needs to be done. However, if the service can support multiple modes and has a certificate or password store, it may not know which authentication model to choose or which credentials to use without being told in the subscription.
Because of the wide variety of capabilites of services, there is no mechanism defined at the message level for negotiating which security profiles may be supported by the service. Instead, the service should export metadata which describes the available options. The format of such metadata is beyond the scope of this particular specification.
WS-Management defines an additional field in the wse:Delivery block which can communicate authentication information:
(1)<s:Body>
(2) <wse:Subscribe>
(3) <wse:Delivery>
(4) <wse:NotifyTo> address </wse:NotifyTo> (5) <wsman:Auth Profile="">
(6) ... (7) </wsman:Auth> (8)
The following describes additional, normative constraints on the outline listed above: wsman:Auth
This block contains authentication information to be used by the service (acting as
publisher) when authenticating to the subscriber (the client) at event delivery time. This block contains a simple string which encodes a token to be used. The format of the token is indicated by the Profile attribute.
wsman:Auth/@Profile
A URI which indicates which security profile to use when authenticating and how to interpret the content of the wsman:Auth block.
If the wsman:Auth block is not present, then the service must infer what to do by using the wse:NotifyTo address using any preconfigured policy or settings it has available.
The available predefined profiles for event delivery are discussed in the following sections.
9.11
Standard profiles
The wsman:Auth block may have no content and the Profile may contain any of the
predefined profiles already defined. In this case, the service must know what credentials to use by its own internal configuration.
For example, if the service knows which certificate to use when delivering events, the subscriber can request standard mutual authentication:
(1)<s:Body>
(2) <wse:Subscribe> (3) <wse:Delivery>
(4) <wse:NotifyTo> HTTPS address </wse:NotifyTo>
(5) <wsman:Auth Profile="wsman:secprofile/https/mutual"/>
Similarly, if the service knows how to retrieve a proper username and password for event delivery, simple HTTP standard authorization can be used:
(6)<s:Body>
(7) <wse:Subscribe>
(8) <wse:Delivery>
(9) <wse:NotifyTo> HTTP address </wse:NotifyTo>
(10) <wsman:Auth Profile="wsman:secprofile/http/standard"/>
There is no requirement that the service support any specific profile. The rest of this section defines special-case profiles for event delivery in which the service needs additional information in order to select the proper credentials to use when delivering events.
9.12
wsman:secprofile/https/standard/userRef
In this profile, the service connects using HTTPS to deliver the event. The receiver's cerficate is used to encrypt the connection, but not to authenticate the sender (the service in this case). Then, the service (acting as the event publisher) uses a standard HTTP Authorizaton header to authenticate. In order to know which user name, password, etc. to use, the subscription contains a reference to it, in which the wsman:Auth block contains a username with no password:
(1)
(3) <wse:Subscribe> (4) <wse:Delivery>
(5) <wse:NotifyTo> address </wse:NotifyTo>
(6) <wsman:Auth Profile="wsman:secprofile/https/standard/userRef"> (7) username="username_literal" realm="realm"
(8) </wsman:Auth> (9) ...
The implication is that at event-time, the service will connect with HTTPS and use wsman:secprofile/https/standard to connect. The Authorization header may already be present, in which case the event delivery will succeed, or it may be absent and the receiving end will challenge with a 401, as described under wsman:secprofile/https/standard.
The service must have access to a password store and look up the password that goes with the username that was specified and carry out the authentication sequence after properly hashing the password (Basic) or processing the nonce (Digest), etc.
The wsman:Auth content block may contain additional information, depending on the authentication model in use:
(10) <wsman:Auth Profile="wsman:secprofile/https/standard/userRef">
(11) username="user" realm="realm" ...and any optional components...
(12) </wsman:Auth>
While it is possible to also supply the password in the subscription so that no store is required on the service side, this is a weak security practice, even though the subscription was delivered over an encrypted connection, since the subscriber is distributing a password to an unknown entity which might not treat them in a secure fashion.
9.13
wsman:secprofile/https/mutual/certhash
In this profile, the service (acting as publisher) connects via HTTPS to the receiver when delivering events, but the certificate to use for authenticating the sender to the receiver is preselected by the subscriber by referencing its hash value or "thumbprint":
(1)<s:Body> (2)<wse:Subscribe>
(3) <wse:Delivery>
(4) <wse:NotifyTo> address </wse:NotifyTo>
(5) <wsman:Auth Profile="wsman:secprofile/https/mutual/certhash"> (6) ef 8f 11 63 97 b8 de 09 a5 d4 73 ed f2 92 35 8e 91 b4 6f 91
(7) </wsman:Auth> (8)...
The format of the block must be a series of hexadecimal digits (upper or lower case), with each octet (two characters) optionally separated by spaces.
The service must be able to locate and use the specified certificate when connecting for event delivery.