EFA WS Trust Policy Provider

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
K (EFA Policy Provider WS-Trust Binding)
K (EFA WS-Trust Binding: requestPolicy)
Zeile 32: Zeile 32:
 
A ECR consumer may use the "Policy Push" paradigm to forward the requestor's ECR access policy to an ECR business service. This requires the ECR consumer to send a request to the ECR Policy Provider service to issue and provide a policy that can be trusted and processed by other ECR services (even in case these services are located on a remote peer).  
 
A ECR consumer may use the "Policy Push" paradigm to forward the requestor's ECR access policy to an ECR business service. This requires the ECR consumer to send a request to the ECR Policy Provider service to issue and provide a policy that can be trusted and processed by other ECR services (even in case these services are located on a remote peer).  
  
Such retrieval of an ECR access policy from an ECR provider's Policy Provider service is bound to the OASIS WS-Trust 1.3 ''RequestSecurityToken (RST)'' and ''RequestSecurityTokenResponse (RSTR)'' messages. This EFA binding introduces extensions and restrictions on the respective WS Trust 1.3 definitions:
+
Such retrieval of an ECR access policy from an ECR provider's Policy Provider service is bound to the OASIS WS-Trust 1.3 ''RequestSecurityToken (RST)'' and ''RequestSecurityTokenResponse (RSTR)'' messages. This EFA binding introduces extensions and restrictions on the respective WS Trust 1.3 definitions.
* Provided Security Token shall comply to the specification of the ECR Policy Assertion.
 
* The Policy Assertion is issued for the requestor and an identified ECR instance. The identifier of the ECR instance (''ecrRef'') is embedded into the RST element as a ''secondary parameter''.
 
* The application of security measures and the contents of the SOAP security header are specified normatively.  
 
  
 
=== Constraints and Extensions to the Request Message (RST) ===
 
=== Constraints and Extensions to the Request Message (RST) ===
Zeile 73: Zeile 70:
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EWuPo.02.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EWuPo.02.03}</tt>
  
If the EFA Policy Provider Service is able to decode the received message and to properly issue a policy it responds with an WS Trust 1.3 RequestSecurityTokenResponse message that carries a single ECR Policy Assertion.
+
If the EFA Policy Provider Service is able to decode the received message and to properly issue a policy it responds with an WS Trust 1.3 RequestSecurityTokenResponse message that carries a single ECR [[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]].
  
 
=== Response Message (Failure or Partial Failure Scenario) ===
 
=== Response Message (Failure or Partial Failure Scenario) ===

Version vom 20. Oktober 2014, 19:22 Uhr

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 .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".


EFA Policy Provider WS-Trust Binding

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.01}

Within EFA the actors and transactions of the OASIS WS-Trust 1.3 standard are mapped onto EFA Policy Provider actors and operations as follows:

Role EFA Policy Provider Service OASIS WS-Trust 1.3
Actor EFA Context Manager Requestor
Actor EFA Policy Provider Security Token Service
Transaction requestPolicy RequestSecurityToken (RST)
RequestSecurityTokenResponse (RSTR)

EFA WS-Trust Binding: requestPolicy

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.02}

A ECR consumer may use the "Policy Push" paradigm to forward the requestor's ECR access policy to an ECR business service. This requires the ECR consumer to send a request to the ECR Policy Provider service to issue and provide a policy that can be trusted and processed by other ECR services (even in case these services are located on a remote peer).

Such retrieval of an ECR access policy from an ECR provider's Policy Provider service is bound to the OASIS WS-Trust 1.3 RequestSecurityToken (RST) and RequestSecurityTokenResponse (RSTR) messages. This EFA binding introduces extensions and restrictions on the respective WS Trust 1.3 definitions.

Constraints and Extensions to the Request Message (RST)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.02.01}

The RequestSecurityToken message is issued by an ECR Context Manager actor for requesting a policy that allows the current user to access an identified ECR instance.

The request message implements a SOAP message including a single RST element as specified in [WS-Trust 1.3] considering the following constraints and extensions:

/wst:RequestSecurityToken/@Context

This optional URI specifies an identifier/context for this request. All subsequent RSTR elements relating to this request MUST carry this attribute. This, for example, allows the request and subsequent responses to be correlated. Note that no ordering semantics are provided; that is left to the application/transport.

/wst:RequestSecurityToken/wst:TokenType

This optional element describes the type of security token requested, specified as a URI. That is, the type of token that will be returned in the <wst:RequestSecurityTokenResponse> message. Token type URIs are typically defined in token profiles such as those in the OASIS WSS TC.

/wst:RequestSecurityToken/wst:RequestType

The mandatory RequestType element is used to indicate, using a URI, the class of function that is being requested. The allowed values are defined by specific bindings and profiles of WS-Trust. Frequently this URI corresponds to the [WS-Addressing] Action URI provided in the message header as described in the binding/profile; however, specific bindings can use the Action URI to provide more details on the semantic processing while this parameter specifies the general class of operation (e.g., token issuance). This parameter is required.

/wst:RequestSecurityToken/wst: SecondaryParameters

If specified, this optional element contains zero or more valid RST parameters (except wst:SecondaryParameters) for which the requestor is not the originator.

/wst:RequestSecurityToken/ecr:EcrRef

Example

...

Expected Actions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.02.02}

...

Response Message (Full Success Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.02.03}

If the EFA Policy Provider Service is able to decode the received message and to properly issue a policy it responds with an WS Trust 1.3 RequestSecurityTokenResponse message that carries a single ECR subjectAccessPolicy.

Response Message (Failure or Partial Failure Scenario)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EWuPo.02.04}

If the EFA Policy Provider Service provider is able to decode the received message but fails to issue the requested policy, ...


Security Audit Considerations

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

See Security Considerations.

Querverweise und Referenzen