cdaefa Diskussion:EFA Identity Assertion SAML2 Binding

ItyAn.01

Comment

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)

Author

ti

Comment Editor

EFA Provider legt @Format fest. Muss dann einheitlich bedient werden, um eindeutige Identifizierung von Benutzern gewährleisten zu können.

ItyAn.01

Comment

Die Subject Confirmation Method sollten wir noch wie besprochen diskutieren. (ti, 07.06.2013)

Author

ti

Comment Editor

HoK stellt keine Hürde für UsernamePassword dar, da symmetrischer Schlüssel generiert werden kann. (Sym. HoK vs. Asym HoK)

ItyAn.01

Comment

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)

Author

ti

Comment Editor

Empfehlung: X509 basiertes Authentifizierungsverfahren SHOULD, andere Authentifizierungsverfahren MAY.

ItyAn.01.02

Comment

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"

Author

ti

Comment Editor

LDAP wie bei P23R

ItyAn.01.02

Comment

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)

Author

ti

ItyAn.01.02

Comment

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)

Author

ti

Comment Editor

rausnehmen, weitere Option: Attribute definiert Cookbook

ItyAn.01.02

Comment

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)

Author

ti

Comment Editor

Organisation ID soll verpflichtend übermittelt werden. Point Of Care soll nicht verpflichtend sein.

ItyAn.01.02

Comment

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)

Author

ti

Comment Editor

optional, siehe Cookbook

ItyAn.01.03

Comment

Für Clinical Speciality bietet sich der epsos Name an: "urn:epsos:names:wp3.4:subject:clinical-speciality". (ti, 07.06.2013)

Author

ti