cdaefa Diskussion:EFA Identity Assertion SAML2 Binding

Aus Hl7wiki
Version vom 16. September 2014, 12:43 Uhr von Jcaumanns (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Change Requests

ID Requester Status Section Change Request Recommendation Editor Discussion
12 - rejected ItyAn.01.02 : HCP Identity Attributes Kodierung von Rollen:

Auf konzeptioneller Ebene sind die Akteure und Rollen genannt:

  • Fallaktenmanager
  • EFA-Provider
  • EFA-Teilnehmer (Verwaltungspersonal, Datenschutzauditor, Audittool, Arzt bzw. med.Fachpersonal)

Auf Implementierungsebene sind dann die HCP Identity Attributes nach ASTM E1986-98 (2005) definiert. In der Annahme, dass sich alle Akteure am EFA-Peer authentisieren müssen und eine SubjectIentityAssertion vorweisen müssen, wäre es sinnvoll, ein Mapping der genannten Rollen auf die entsprechenden Identity Attributes klar zu definieren (zusätzlich zu einem Beispiel für Ärzte, das bereits vorhanden ist)

jc: Manchmal besser erst denken... (bezogen auf den Vorschlag unten)

Die EFA-Rolle kann garnicht in der HCP-Identity Assertion enthalten sein, da diese Rolle aus dem Consent abgeleitet wird. Derr Consent liegt potenziell bei dem die HCP-Assertion ausstellenden Identity Provider garnicht vor - bzw. dieser hat kein Zugriffsrecht auf den Consent. Daher kann die EFA-Rolle erst im Rahmen der Policy Decision abgefragt und ausgewertet werden.

jc: Idealerweise sollte hier das bestehende EFA-Codesystem "HCP Roles" referenziert werden. Ggf. kann man ja auch die Angabe der EFA-Rolle verpflichetend machen und die ASTM-Rolle optional.

Kommentare

ID Author Status Section Vote Existing Proposed Comment Comment Editor Discussion
236 ti included ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions Die Subject Confirmation Method sollten wir noch wie besprochen diskutieren. (ti, 07.06.2013) HoK stellt keine Hürde für UsernamePassword dar, da symmetrischer Schlüssel generiert werden kann. (Sym. HoK vs. Asym HoK). Bearer ist jetzt auch zulässig. Hierfür muss gelten: Die Nachrichten werden über einen gegenseitig authentifizierten TLS-Kanal ausgetauscht.
237 ti included ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions Wenn als AuthnContextClassRef nur urn:oasis:names:tc:SAML:2.0:ac:classes:X509 verwendet werden darf, heisst dass dann das kein Benutzer über Benutzername+Passwort identifiziert werden darf? In {Eecim.02.02} unter "Art der Authentifizierung" deutet die Formulierung ja eher auf eine Entscheidung des EFA Providers hin, welche Authentifizierungsmethoden er bei IdPs erwartet. (ti, 07.06.2013) Es sind jetzt grundsätzlich alle Verfahren zulässig, können vom PEP aber abgelehnt werden. Empfehlung: X509 basiertes Authentifizierungsverfahren SHOULD, andere Authentifizierungsverfahren MAY.
238 ti rejected ItyAn.01 : SAML 2.0 Profile for ECR Identity Assertions Um unnötige Mapping-Schritte zu vermeiden, sollte die NameID soweit eingeschränkt werden, dass sie ohne weiteres in die XACML engine gegeben und mit der policy verglichen werden kann. Selbst die Deutschland-spezifischen Einschränkungen in {ItyAn.01.05} sind hier noch zu flexibel. Ich würde hier jeweils eine einzige Definition für Niedergelassene und Ärzte in Einrichtungen vorschlagen. Zumindest sollte dem Leser klar gemacht werden dass die NameID mit den Policies abgeglichen wird und somit der Ersteller der Policies den gleichen Identifikator verwendet. Wenn dies nicht der Fall ist, könnte es passieren dass der IdP die ID des HBA AUT Zertifikats verwendet, die Policy aber auf eine bestimmte Lebenslange Arztnummer der KV des gleichen Arztes abgleicht. (ti, 07.06.2013) EFA Provider legt @Format fest. Die NameID muss dann einheitlich bedient werden, um eindeutige Identifizierung von Benutzern gewährleisten zu können. Die Abhängigkeit zwischen SAML-NameID und XACML-Subject-MatchID ist im Policy Assignment SAML-Binding beschrieben.
239 ti commented ItyAn.01.02 : HCP Identity Attributes HP Identifier: XSPA definiert hier "urn:oasis:names:tc:xacml:1.0:subject:subject-id" als Attributsnamen, während XUA "urn:oasis:names:tc:xspa:1.0:subject:subject-id" verwendet, was doppelt falsch ist: weder ist es wirklich eine ID, noch ist es von XSPA mit dieser URN versehen worden. Beide Alternativen haben den Nachteil, dass sie die Referenzierung auf die primäre ID des Benutzers in einer XACML policy unnötig erwschweren. Da die primäre ID des Benutzers in SAML nicht als AttributeStatement mit name und type sondern als NameID Element übertragen wird, gibt es keinen "natürlichen" Attributsnamen um in einer Policy einen bestimmten Benutzer zu authorisieren. Die logischste URN dafür wäre eigentlich "urn:oasis:names:tc:xacml:2.0:subject:subject-id" (ob 1.0 oder 2.0 ist dabei nicht entscheidend). Daher würde ich mich gegen die von XSPA (und z.T. von XUA) gewählte Umdefinition des Klarnamens zur "subject-id" aussprechen. Der Klarname kann auch viel besser mit Rückgriff auf den LDAP Standard definiert werden. Im XACML Core wird dies auf Seite 129 (ab Zeile 5027) als Pflicht (zumindest für den XACML Request Context) für in LDAP schon existierende Attribute definiert: "Where a suitable attribute is already defined in LDAP [LDAP-1, LDAP-2], the XACML identifier SHALL be formed by adding the attribute name to the URI of the LDAP specification. For example, the attribute name for the userPassword defined in the RFC 2256 SHALL be: http://www.ietf.org/rfc/rfc2256.txt#userPassword". Daher mein Vorschlag: "urn:oasis:names:tc:xacml:2.0:subject:subject-id" in XACML policies bezeichnet den primären Identifier des Benutzers, "http://www.ietf.org/rfc/rfc2256.txt#cn" im SAML AttributeStatement und im XACML Request Context bezeichnet den Klarnamen des Benutzers. (ti, 07.06.2013) Im Zuge von der Peer2Peer-Ausarbeitung werden die HCP Identity Attribute um ein weiteres SAML-AttributeStatement erweitert, welches auf dem SAML V2.0 X.500/LDAP Attribute Profile basieren wird.
240 ti included ItyAn.01.02 : HCP Identity Attributes Purpose of Use: 1. Für PoU würde ich auch auf einen strukturierten Typ setzen, wie auch in XUA definiert. Also "urn:hl7-org:v3#CE" oder "urn:hl7-org:v3#CV". 2. Im Cookbook haben wir das Attribut nicht mandatory gesetzt, sondern stattdessen Treatment bzw. den ungefähr equivalenten Wert 1 aus ISO 14265 als Default Wert annehmen muss. Dies erlaubt eine explizite Nennung bei Ausnahmen (v.a. Notfallzugriff) ohne dem Client zuviel abzuverlangen. (ti, 07.06.2013) optional, siehe Cookbook
241 ti included ItyAn.01.02 : HCP Identity Attributes Healthcare Professional Organisation und Healthcare Professional Organisation ID: Ich würde zumindest die Organisation ID immer zwingend übertragen. Aus Sicht der Authorisierung von Einrichtungen erscheint mir die organisatorische Zugehörigkeit als das kritischere Unterscheidungsmerkmal. Ich vermute mal Point of Care ist mandatory und als Grundlage für die Policies gedacht, um den Fall des Belegarzt abzudecken, dessen Daten nicht im KH System landen sollen, mit dem er manchmal auf Fallakten zugreift. Dieser Fall sollte adressiert werden, aber locality scheint mir nicht die optimale Lösung zu sein. Erstens ist es ein Environment Aspekt und nicht Teil des Subjects. Zweitens ist es im Gegensatz zur Organisation ID nicht in IHE XUA definiert. Wenn locality eingesetzt wird, würde ich ausserdem die Definition von XSPA vorziehen: "Unique identifier of the servicing organization". Zusätzlich würde ich auch den Type einschränken: "URN encoded OID of the Healthcare Professional Organisation" (wie bei Org-ID). (ti, 07.06.2013) Organisation ID soll verpflichtend übermittelt werden. Point Of Care soll nicht verpflichtend sein.
242 ti postponed ItyAn.01.02 : HCP Identity Attributes Structural Role of the HCP: 1. XUA erweitert erlaubt ausser ASTM E1986 auch SNOMED CT und ISO 21298 - hatten wir uns nicht in der 7er Gruppe vorläufig eher für SNOMED ausgesprochen? 2. Wenn die Rolle auf die hier beschriebenen eingeschränkt wird, wie wird dann z.B. der Fallaktenmanager abgebildet? 3. Ich würde für die Rolle einen strukturierteren Datentyp wählen. XUA sieht "urn:hl7-org:v3#CE" vor, ich hätte eher CV gewählt. Aus Sicht des Cookbooks ist es durchaus wichtig unterschiedliche Codesysteme unterstützen zu können, gerade auch um die unterschiedlichen Aktentypen abbilden zu können. (ti, 07.06.2013) Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk) Die gültigen Werte für dieses Attribut sollten im Cookbook festgelegt werden. (ti)
243 ti included ItyAn.01.03 : German Extensions Für Clinical Speciality bietet sich der epsos Name an: "urn:epsos:names:wp3.4:subject:clinical-speciality". (ti, 07.06.2013) Sobald die TI ausgerollt ist, kann dieses Attribut verwendet werden. Für das Policy-Enforcement ist es zur Zeit nicht relevant. Daher wird an dieser Stelle keine Alternative zum TI-Attribut vorgeschlagen. Hinweis wurde eingefügt.

Authors

Kürzel Name Organisation E-Mail
fh Frank Oemig Agfa Healthcare
ti Tarik Idris InterComponentWare AG
mr Michael Rübener X-tension
sh Salima Houta Fraunhofer ISST
jc Jörg Caumanns Fraunhofer FOKUS
bk Ben Kraufmann Fraunhofer FOKUS
iw Ingo Wolf gematik
mk Marcel Klötgen CompuGroup Medical