federated directory services revised proposal for 2009/10 presented to the it infrastructure...

Federated Directory ServicesFederated Directory Services

Revised Proposal for 2009/10Revised Proposal for 2009/10presented to thepresented to the

IT Infrastructure Planning CommitteeIT Infrastructure Planning CommitteeJ. Caumanns, O. Rode, R. Kuhlisch, FHGISSTJ. Caumanns, O. Rode, R. Kuhlisch, FHGISST

12 October 200912 October 2009

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Problem Statement

• 2008: 1 Proposal for a directory profile2008: 1 Proposal for a directory profile• 2009: 3 Proposals for directory profiles2009: 3 Proposals for directory profiles

• as use cases show, directories on services and as use cases show, directories on services and organisations are a mandatory prerequisite for distributed organisations are a mandatory prerequisite for distributed healthcare networkshealthcare networks

• FDS Essentials:FDS Essentials:– Separation of schemas from query and mgmt. infrastructureSeparation of schemas from query and mgmt. infrastructure– authonomy of directory providersauthonomy of directory providers– multiple deployment options: P2P, Master-Slave, Hierarchy, ....multiple deployment options: P2P, Master-Slave, Hierarchy, ....


• The focus of the proposed implementable white paper is on The focus of the proposed implementable white paper is on the “envelope” for directory queries and on mechanisms for the “envelope” for directory queries and on mechanisms for forwarding such queries among directory services in order forwarding such queries among directory services in order to allow for the implementation of different directory to allow for the implementation of different directory topologies (e.g. hierarchy, master-slave, P2P, centralized).topologies (e.g. hierarchy, master-slave, P2P, centralized).

• The FDS actors and transactions will extend the existing The FDS actors and transactions will extend the existing PWP profile and the proposed profiles on configuration and PWP profile and the proposed profiles on configuration and provider directories with functionalities for cross-domain provider directories with functionalities for cross-domain directory linkage.directory linkage.


FDS Topology

Domain 1

FDS

Domain 2

FDS

virtual integrateddirectory

Local Directories

Local Directories

Local Dirs

UserUser

User

Domain 3

FDS


HITPR Topology

Domain 1

FDS

Domain 2

FDS

virtual integrateddirectory

Local Directories

Local Dirs

User

Domain 3

FDS

Provider

Provider


FDS Directory Integration

Dire

ctor

ies

FDS

join

ed n

ames

pace

s

dom=Domain 1 dom=Domain 2

root

dom=Domain 3

dir=IHE Personnel WP

dir=IHE Org. WP

dir=IHEServices WP


dir=Some Regional WP

dir=IHEServices WP


dir=IHE Org. WP

dir=IHEServices WP

dir=HITPRProvider

dir=HITPRProvider


Directory Schema Co-Existence

Dire

ctor

ies

FDS

join

ed n

ames

pace

s

dom=Domain 1 dom=Domain 2

root

dom=Domain 3


dir=IHE Org. WP

dir=IHEServices WP



dir=IHEServices WP


dir=IHE Org. WP

dir=IHEServices WP

dir=HITPRProvider

dir=HITPRProvider

DSDSHITPR

DODS


Sample: Find Service URL by OID


Proposed Standards & Systems

• DSML v2 to query (LDAP) directoriesDSML v2 to query (LDAP) directories– LDAP2UDDI adaptors available from industry LDAP2UDDI adaptors available from industry

• IHE PWP as basis and referenceIHE PWP as basis and reference– RFC2798 (inetOrgPerson), RFC2256 (X500 user schema) RFC2798 (inetOrgPerson), RFC2256 (X500 user schema)

• IHE ATNA for FDS AuthenticityIHE ATNA for FDS Authenticity• IHE XUA to support access controlIHE XUA to support access control• IHE White Paper on Cross-Community Information IHE White Paper on Cross-Community Information

ExchangeExchange

• Alternatives to discuss (in January....):Alternatives to discuss (in January....):– OMG IS (former EIS)OMG IS (former EIS)– UDDIUDDI


Scope of the White Paper

• Upper Directory Tree structure (more or less implied)Upper Directory Tree structure (more or less implied)• Client and P2P query transactions (DSML v2)Client and P2P query transactions (DSML v2)• Registration of FDS for a certain domainRegistration of FDS for a certain domain• security issues (mainly ATNA)security issues (mainly ATNA)

Directory Consumer Directory Gateway

Directory Provider

searchDirectory

searchDirectory

forwardSearchRequest

DNS Server

findDirectory[ITI-23]


Discussion

• Editor: Fraunhofer ISSTEditor: Fraunhofer ISST• Editing support by: Swisssign, ELGA, iSoft, ISProEditing support by: Swisssign, ELGA, iSoft, ISPro• Estimated Effort: LowEstimated Effort: Low

• Prototype implementation as “proof of concept” at Prototype implementation as “proof of concept” at Fraunhofer ISSTFraunhofer ISST

• integration with eCR v1.4 (2010) planned and agreed with integration with eCR v1.4 (2010) planned and agreed with industry; deployment into running eCR pilot projects and industry; deployment into running eCR pilot projects and running networks late 2010running networks late 2010


WP Outline [#pages]

• Use cases (incl. deployment and topology options): Use cases (incl. deployment and topology options): [3][3]• Multi-Schema support (IHE directory profiles): Multi-Schema support (IHE directory profiles): [2][2]• actors and transactions (functional): actors and transactions (functional): [2][2]• transaction specification (technical): transaction specification (technical): [3][3]• security considerations (use of ATNA and XUA): security considerations (use of ATNA and XUA): [2][2]• management considerations (adding and removing management considerations (adding and removing

directories): directories): [2][2]• routing (optimization of query forwarding): routing (optimization of query forwarding): [1][1]

[15][15]


Discussion

• Alternatives:Alternatives:– IHE ITI designs each directory service from scratch, including IHE ITI designs each directory service from scratch, including

actors, transactions, and schemasactors, transactions, and schemas– other IHE domains design directory schemas and transactions that other IHE domains design directory schemas and transactions that

then have to be integrated afterwards by ITIthen have to be integrated afterwards by ITI

• Facts:Facts:– every distributed EHR needs a service directory. every distributed EHR needs a service directory.

• No distributed EHR – No demand for directories (and vice versa)No distributed EHR – No demand for directories (and vice versa)• No service directory – no distributed EHRNo service directory – no distributed EHR

– XUA makes no sense for safeguarding XDS etc. without an XUA makes no sense for safeguarding XDS etc. without an organisation directoryorganisation directory

federated directory services revised proposal for 2009/10 presented to the it infrastructure...

Documents