EFA Identity Provider Service Functional Model
(Die Seite wurde neu angelegt: „Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen EFA Sicherheitskontext zwischen Client un…“) |
K |
||
Zeile 1: | Zeile 1: | ||
+ | {{Infobox Dokument | ||
+ | |Title = EFA Identity Provider Service Functional Model | ||
+ | |Short = EFA Identity Provider Service Functional Model | ||
+ | |Namespace = cdaefa | ||
+ | |Type = Implementierungsleitfaden | ||
+ | |Version = 0.9 | ||
+ | |Submitted = February 2013 | ||
+ | |Author = Jörg Caumanns, Raik Kuhlisch | ||
+ | |Date = March 2013 | ||
+ | |Copyright = 2012-2013 | ||
+ | |Status = Draft | ||
+ | |Period = xxx | ||
+ | |OID = n.n. | ||
+ | |Realm = Deutschland | ||
+ | }} | ||
+ | |||
+ | ''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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".'' | ||
+ | ---- | ||
+ | |||
+ | == EFA Identity Provider == | ||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Edtie.01}</tt> | ||
+ | |||
Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen [[cdaefa:EFA_Context_Manager_SFM|EFA Sicherheitskontext]] zwischen Client und EFA-Provider aufzubauen. Ein Client, der sich gegenüber einen EFA Identity Provider (über die [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|OpenContext-Operation]]) authentisiert, muss dazu Credentials für seine behauptete Identität vorlegen, welche serverseitig überprüft werden. | Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen [[cdaefa:EFA_Context_Manager_SFM|EFA Sicherheitskontext]] zwischen Client und EFA-Provider aufzubauen. Ein Client, der sich gegenüber einen EFA Identity Provider (über die [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|OpenContext-Operation]]) authentisiert, muss dazu Credentials für seine behauptete Identität vorlegen, welche serverseitig überprüft werden. | ||
− | |||
− | |||
Der EFA Identity Provider bietet als Schnittstelle zum Client nur eine Operation zur Authentifizierung an. Da der EFA Identity Provider ist als Sicherheitstokendienst deployt ist, erstellt er bei positiver Authentifizierung einen Nachweis als Sicherheitstoken, nämlich die HP Identity Assertion. Die EFA 2.0 Spezifikation macht keine spezifischen Vorgaben, wie das Protokoll ausgestaltet ist. Als Vorgabe gilt hingegen das IHE-Profil [[IHE_DE_Cookbook#Cross-Enterprise_User_Assertion_.28XUA.29|Cross-Enterprise User Assertion (XUA)]], welches ein Binding auf das SAML- oder WS-Tust-Protokoll spezifiziert (siehe [[cdaefa:EFA_XUA_Binding| EFA XUA Binding]]). Der Authentifizierungsnachweis kann weitere Attribute eines EFA-Teilnehmers aus einem [[IHE_DE_Cookbook#Healthcare_Provider_Directory_.28HPD.29|Healthcare Provider Directory (HPD)]] enthalten, welche später für eine Zugriffskontrolle genutzt werden. | Der EFA Identity Provider bietet als Schnittstelle zum Client nur eine Operation zur Authentifizierung an. Da der EFA Identity Provider ist als Sicherheitstokendienst deployt ist, erstellt er bei positiver Authentifizierung einen Nachweis als Sicherheitstoken, nämlich die HP Identity Assertion. Die EFA 2.0 Spezifikation macht keine spezifischen Vorgaben, wie das Protokoll ausgestaltet ist. Als Vorgabe gilt hingegen das IHE-Profil [[IHE_DE_Cookbook#Cross-Enterprise_User_Assertion_.28XUA.29|Cross-Enterprise User Assertion (XUA)]], welches ein Binding auf das SAML- oder WS-Tust-Protokoll spezifiziert (siehe [[cdaefa:EFA_XUA_Binding| EFA XUA Binding]]). Der Authentifizierungsnachweis kann weitere Attribute eines EFA-Teilnehmers aus einem [[IHE_DE_Cookbook#Healthcare_Provider_Directory_.28HPD.29|Healthcare Provider Directory (HPD)]] enthalten, welche später für eine Zugriffskontrolle genutzt werden. | ||
Zeile 37: | Zeile 57: | ||
|Authentication failed due to wrong credentials. | |Authentication failed due to wrong credentials. | ||
|} | |} | ||
+ | |||
+ | === Querverweise und Referenzen === | ||
+ | |||
+ | * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] |
Version vom 23. April 2013, 07:30 Uhr
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA Identity Provider Service Functional Model (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
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 Identity Provider
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Edtie.01}
Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen EFA Sicherheitskontext zwischen Client und EFA-Provider aufzubauen. Ein Client, der sich gegenüber einen EFA Identity Provider (über die OpenContext-Operation) authentisiert, muss dazu Credentials für seine behauptete Identität vorlegen, welche serverseitig überprüft werden.
Der EFA Identity Provider bietet als Schnittstelle zum Client nur eine Operation zur Authentifizierung an. Da der EFA Identity Provider ist als Sicherheitstokendienst deployt ist, erstellt er bei positiver Authentifizierung einen Nachweis als Sicherheitstoken, nämlich die HP Identity Assertion. Die EFA 2.0 Spezifikation macht keine spezifischen Vorgaben, wie das Protokoll ausgestaltet ist. Als Vorgabe gilt hingegen das IHE-Profil Cross-Enterprise User Assertion (XUA), welches ein Binding auf das SAML- oder WS-Tust-Protokoll spezifiziert (siehe EFA XUA Binding). Der Authentifizierungsnachweis kann weitere Attribute eines EFA-Teilnehmers aus einem Healthcare Provider Directory (HPD) enthalten, welche später für eine Zugriffskontrolle genutzt werden.
Method | requestHPIdentityAssertion()(credential Object) : HPIdentityAssertion | |
---|---|---|
Description | This method authenticates a user by means of an EFA Identity Provider. If necessary the EFA Identity Provider calls more user attributes from a HPD. A credential MUST be passed. | |
Input Parameters | credential | Object which MAY be a username/password combination, a subject identifier, a health card handle, or a SAML assertion that guarantees for an authentication. |
Return Value | HP Identity Assertion | The assertion confirms the successful authentication. |
Preconditions |
| |
Sequence (Main success scenario) |
| |
Exception | AuthenticationFailedException | Authentication failed due to wrong credentials. |