DICOM PS3.7 2024e - Message Exchange |
---|
The User Identity Negotiation is used to notify the association acceptor of the user identity of the association requestor. It may also request that the association acceptor respond with the server identity. This negotiation is optional. If this sub-item is not present in the A-ASSOCIATE request the A-ASSOCIATE response shall not contain a user identity response sub-item.
The Association-requestor conveys in the A-ASSOCIATE request:
The Association-acceptor does not provide an A-ASSOCIATE response unless a positive response is requested and user authentication succeeded. If a positive response was requested, the A-ASSOCIATE response shall contain a User Identity sub-item. If a Kerberos ticket is used the response shall include a Kerberos server ticket.
Since a system may ignore request sub-items, the positive response must be requested if the association requestor requires confirmation. If the association acceptor does not support user identification it will accept the association without making a positive response. The association requestor can then decide whether to proceed.
The association acceptor may utilize the User Identity information provided during the association negotiation to populate the user information fields in DICOM audit trail messages. The association acceptor may utilize the User Identity information provided during the association negotiation to perform authorization controls during the performance of other DIMSE transactions on the same association. The user identity information may also be used to modify the performance of DIMSE transactions for other purposes, such as workflow optimizations.
User identity authorization controls may be simple "allow/disallow" rules, or they can be more complex scoping rules. For example, a query could be constrained to apply only to return information about patients that are associated with the identified user. The issues surrounding authorization controls can become very complex. The User Identity Negotiation conveys user identity to support uses such as authorization controls and audit controls. It does not specify their behavior.
The option to include a passcode along with the user identity enables a variety of non-Kerberos secure interfaces. Sending passwords in the clear is insecure, but there are single use password systems such as [RFC2289] and the various smart tokens that do not require protection. The password might also be protected by TLS or other mechanisms.
For JSON Web Tokens (JWTs), [RFC7519] specifies minimal requirements for encryption, MAC and signature algorithms; others may be supported as described in the DICOM Conformance Statement. The encoded format in the Primary-field of the A-ASSOCIATE-RQ is the same as what might be included in an HTTP Authorization: Bearer header field per [RFC6750] when accessing a Protected Resource on a Resource Server. If the same trust mechanisms are used by both the DIMSE SCP and the Resource Server, the contents of the Primary-field can be the same as the value of the HTTP Authorization: Bearer field, avoiding the need to perform a conversion of the contents.
Care should be taken to not include unnecessary protected content from the User Identity Negotiation into audit log messages. For example, the password, SAML Assertion, and JSON Web Token (JWT) could be disclosed if included in a log message. A service such as the OAuth Introspection Service ([RFC7662]) might be needed to obtain unprotected user identity information from a SAML Assertion or JWT.
The User Identity Negotiation Sub-Item shall be made of a sequence of mandatory fixed and variable length fields. This Sub-Item is optional and if supported, only one User Identity Negotiation Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-14 shows the sequence of the mandatory fields.
Table D.3-14. User Identity Negotiation Sub-Item Fields (A-ASSOCIATE-RQ)
This reserved field shall be sent with a value 00H but not tested to this value when received. |
||
This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the last field sent. It shall be encoded as an unsigned binary number. |
||
Field value shall be in the range 1 to 5 with the following meanings: 1 - Username as a string in UTF-8 |
||
The User-Identity-Length shall contain the length of the User-Identity value. |
||
This field shall convey the user identity, either the username as a series of characters, or the Kerberos Service ticket encoded in accordance with [RFC1510], or the JWT encoded in accordance with [RFC7519] using base64url encoded parts. |
||
This field shall be non-zero only if User-Identity-Type has the value 2. It shall contain the length of the secondary-field. |
||
This field shall be present only if User-Identity-Type has the value 2. It shall contain the Passcode value. |
DICOM PS3.7 2024e - Message Exchange |
---|