DICOMWeb user authentication

Considering the needs of a proxy

DICOM has taken the approach of letting other standards development organizations and regulators specify security requirements to the extent practical. DICOM has written security requirements and profiles to fill gaps and ensure interoperability when necessary.

Interoperability in this context means that the purchasers or users of DICOM equipment can easily determine whether two pieces of equipment will interoperate. It does not mean that they will always interoperate. DICOM does not expect a CT system to be able to act like a storage service for a CR system. DICOM does specify association negotiation rules and conformance claim rules to make it “easy” to determine whether two systems will interoperate and what functions will be provided. (The easy is in quotes because the variety of system types, capabilities, and details covered in a conformance claim is overwhelming to the novice.)

The question has arisen of what should DICOM specify regarding security for DICOMWeb connections? At present DICOM has a few relevant specifications:

1. The mechanisms for use of TLS are specified. (The use is optional, but if TLS is used it shall be used as specified.)

2. There are some TLS profiles. These apply to both DIMSE and DICOMWeb traffic. One corresponds to the IETF BCP195 recommendations adjusted to incorporate some of the requirements and restrictions of DICOM. The other adds the Camilla encryption capabilities and denies use of TLS 1.2 to the BCP195 profile. Offering these profiles means that a device can be configured to comply with the profile rules. It does not require that the device only be so configured. That is covered in the device’s conformance claim.

3. There is a section in the conformance claim for “security related information”. There are no requirements or further advice about what might go here.

There are also other security related sections that are not connection related, such as attribute level digital signatures and attribute confidentiality profiles.

Proxy mapping

One heuristic for evaluating DICOMWeb specifications has been the “proxy capability” analysis. In its simplest form it is:

What capabilities and requirements are needed so that a proxy system can be implemented that translates losslessly between a DIMSE connection and a DICOMWeb connection. (A proxy need not actually be implemented. This is a design evaluation technique to detect mistakes.)

Using that evaluation, one question is: If a DIMSE association request attempts to perform user identity negotiation, what is the corresponding HTTP behavior? What is the reverse behavior when a DICOMWeb request is converted into DIMSE?

From DIMSE to HTTP (DICOMWeb)

DIMSE define five kinds of user identity assertion. What is the HTTP behavior that corresponds to user identity assertions specifying:

1. Username only (as a string)

2. Username/Password

3. Kerberos Service Ticket

4. SAML Assertion

5. JSON Web Token (JWT)

Username, and Username/Password

Some form of HTTP Basic authentication looks like a reasonable mapping, but there are several possible approaches. RFC7235 provides one such mapping. RFC7617 also covers this.

Authorization: Basic dGVzdDoxMjPCow==

Kerberos Service Ticket

RFC4559 looks relevant. It’s not clear how important this mapping will be in the field.

SAML Assertion and JSON Web Token

It looks like these should both be encoded as Authorization: Bearer tokens

 Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
    iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
    FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
    zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
    dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
    vmDCMy5-kdXjwhw

These are relevant for modern HTTP uses because SAML Assertions and JWT tokens are used by the OAuth and related identity mechanisms. But, SAML and JWT tokens are more often used in the context of authorization and authentication negotiation, not as access control tokens on individual requests. The typical pattern is some separate transactions, perhaps involving SAML Assertions and JWT tokens, to get Access tokens, and other tokens. The HTTP transactions that move data, e.g., the DICOMWeb and FHIR transactions, use Access tokens.

From HTTP (DICOMWeb) to DIMSE

Basic Access Token

A HTTP request with an Authorization: Basic could be used for many different possible assertions. The proxy will have to look inside the token to determine what is meant.

Bearer Access Token

Access tokens are not one of the DIMSE User Identification types. Bearer Access tokens are very commonly used in HTTP transactions, see RFC6750. FHIR has specified that individual HTTP transactions be authorized by an Authorization: Bearer <token> header. This header might be encoded like:

Authorization: Bearer mF_9.B5f-4.1JqM

An access token can also be URI Query encoded, although URI encoding is becoming less popular:

GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1

Documenting whether Authorization header or URL encoded is used might be something covered in the conformance claim. Or, DICOM could express an opinion and specify a profile. It’s unlikely that DICOM should specify the choice.

Since SAML, JSON, and other token types are all encoded into Authorization: Bearer headers, a proxy would have to open up the token to map it to SAML or JSON.

DIMSE user identity negotiation could have a “Authorization: Bearer token” added. This might also make integration of DIMSE with services like OAUTH easier.

Multiple authentications in one header

What if the HTTP headers include both a basic authorization token and a bearer authorization token? What can be said about how a proxy should behave?