EFA XDS SecurityConsiderations

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Security Considerations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.05}

Message Protection

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.05.01}

The ECR requester MUST apply means to achieve message authenticity, message integrity and message confidentiality. The EFA Resource Manager MUST approve at least one of the following mechanisms.

Transport Layer Security with SAML Issued Endorsing Token

The request message and the response message are sent over an EFA Resource Manager authenticated TLS-channel. In the SOAP Security Header the EFA client provides an EFA Identity Assertion and a wsu:timestamp element. If the SAML subject confirmation method is set to holder-of-key the wsu:timestamp element MUST be signed with the Subject-Confirmation-Key. If the SAML subject confirmation method is set to bearer the TLS-channel MUST be mutually authenticated.

EFA XDS RM SC TLS.png

WS-Security-Policy Example
<wsp:Policy wsu:Id="ServicePortBindingPolicy">
    <sp:TransportBinding>
        <wsp:Policy>
            <sp:TransportToken>
                <wsp:Policy>
                    <sp:HttpsToken RequireClientCertificate="false" />
                </wsp:Policy>
            </sp:TransportToken>
            <sp:AlgorithmSuite>
                <wsp:Policy>
                    <sp:Basic256Sha256 />
                </wsp:Policy>
            </sp:AlgorithmSuite>
            <sp:IncludeTimestamp />
            <sp:Layout>
                <wsp:Policy>
                    <sp:Strict />
                </wsp:Policy>
            </sp:Layout>
        </wsp:Policy>
    </sp:TransportBinding>
    <sp:Wss11>
        <wsp:Policy />
    </sp:Wss11>
    <wsam:Addressing />
</wsp:Policy>
<wsp:Policy wsu:Id="Input_Policy">
    <sp:EndorsingSupportingTokens>
        <wsp:Policy>
            <sp:IssuedToken
                sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeTokenAlwaysToRecipient">
                <sp:RequestSecurityTokenTemplate>
                    <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
                    <wst:KeySize>2048</wst:KeySize>
                </sp:RequestSecurityTokenTemplate>
                <wsp:Policy></wsp:Policy>
            </sp:IssuedToken>
        </wsp:Policy>
    </sp:EndorsingSupportingTokens>
</wsp:Policy>

Asymmetric Message Protection

The request message and the response message are signed and encrypted. The ECR requester uses the key material corresponding with the Subject-Confirmation-Key provided with the issued EFA Identity Assertion. The EFA Provider uses its service certificate and key. The wsu:timestamp element, all WS-Addressing elements and the SOAP-Body element MUST be signed. The SOAP-Body element MUST be encrypted.

WS-Security-Policy Example
<wsp:Policy wsu:Id="ServicePortBindingPolicy">
    <sp:AsymmetricBinding>
        <wsp:Policy>
            <sp:InitiatorToken>
                <wsp:Policy>
                    <sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                        <sp:RequestSecurityTokenTemplate>
                            <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
                            <wst:KeySize>2048</wst:KeySize>
                        </sp:RequestSecurityTokenTemplate>
                        <wsp:Policy></wsp:Policy>
                    </sp:IssuedToken>
                </wsp:Policy>
            </sp:InitiatorToken>
            <sp:RecipientToken>
                <wsp:Policy>
                    <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToInitiator">
                        <wsp:Policy><sp:WssX509V3Token10 /></wsp:Policy>
                    </sp:X509Token>
                </wsp:Policy>
            </sp:RecipientToken>
            <sp:AlgorithmSuite><wsp:Policy><sp:Basic256 /></wsp:Policy></sp:AlgorithmSuite>
            <sp:Layout><wsp:Policy><sp:Strict /></wsp:Policy></sp:Layout>
            <sp:IncludeTimestamp />
            <sp:OnlySignEntireHeadersAndBody />
        </wsp:Policy>
    </sp:AsymmetricBinding>
    <sp:Wss11><wsp:Policy></wsp:Policy></sp:Wss11>
    <sp:Trust10>
        <wsp:Policy><sp:MustSupportIssuedTokens /></wsp:Policy>
    </sp:Trust10>
    <wsap10:UsingAddressing />
</wsp:Policy>

WS-SecureConversation bootstrapped with SAML Issued Token

The request message and the response message are signed and encrypted. Both the ECR requester and the EFA Provider use a symmetric Secure-Conversation-Token key. The Secure-Conversation-Token MUST reference the issued EFA Identity Assertion. The wsu:timestamp element, all WS-Addressing elements and the SOAP-Body element MUST be signed. The SOAP-Body element MUST be encrypted.

Audit Trail

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.05.02}

Service consumer and service provider actors SHALL write an audit trail according to the EFAv2 Audit Trail Binding.