Authenticating and authorizing service account

[Ryan Crichton]

Hi all,

I'l like to start a discussion around the authentication and authorization of service accounts within OpenHIE. We started this discussion late on the architecture call yesterday so hopefully we can continue some of that here.

On the call we made the distinction between:

• Human users - Physical user that want to interact with a system directly
• Service users - Accounts that allows a system to access another system automatically

I want to talk about the latter in more depth.

On the call we discussed that the domain services (registries etc.) should either support their own authentication and authorization mechanism or make use of a single sign-on service supported by the Provider Registry. Now, if we start to think about service users it definitely does not make sense to store this in the Provider Registry as there is no physical user (provider) to back the account details. Also, single sign-on doesn't seem to make sense if we are using a central interoperability layer as all communication is directed through the interoperability layer and the systems doesn't need to be accessed directly.

So, we will have to support a separate mechanism for this sort of authentication and authorization. Is it feasible for each domain service to support two different mechanisms? 1 for human users and 1 for service users? To me this seems like too much complexity.

Perhaps, a single separate authentication and authorization service is needed for both human and service users?

I wonder what other think about this.

Cheers,

Ryan

--

Ryan Crichton

Software Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

[Burke Mamlin]

Managing non-human users for authentication seems like a smaller challenge than trying to support and consistently apply two separate mechanisms of authentication, since I'd presume that 99% of the code would behave the same whether the "user" was human or not.  

-Burke

--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Derek Ritz]

Hi Ryan.

A "service user" simply needs to be authenticated... not authorized. This authentication might be thought of as operationalizing the idea that: "the Interoperability Layer will never talk to strangers". Authentication may be achieved through IHE's ATNA profile (for example), which stands for Audit Trail and Node Authentication. In ATNA, node authentication uses PKI to establish that an end point is "known". It really shouldn't be thought of as analogous to logging into an application... it is actually implemented at the network level (quite a few layers lower in the OSI "stack").

Authority is different from authentication. The latter answers the question: "who are you?" Authorization, however, answers the question: "what are you allowed to do?"  Here is where we are well-served by our very broad definition of the the Provider Registry as containing a record for every health system worker. The Provider Registry will contain a superset of clinicians that includes administrative and technical staff who support the health system. We can include, as attributes of each health system worker, information regarding their "authority". Every transaction that is submitted to the Interoperability Layer will indicate the user who is submitting it (not just the node... the authenticated user). Our ability to do this is based on the web of trust idea; a node will not be granted access to the Interoperability Layer unless it's ability to authenticate end-users is trusted. For example, if an OpenMRS server is assigned a PKI certificate and is now "known" to the Interoperability Layer, it is required that each transaction conveyed by that OpenMRS instance will also convey the user login ID (by definition, a local provider ID) and the Interoperability Layer will trust that this ID is the authenticated provider.

For users who are doing registry maintenance, the registries will need to abide by the same "rules" as the Interoperability Layer does. Since these registries are inside the firewall of the datacentre, they cannot be allowed to let strangers in. Likewise, they will need to enforce rules regarding what authority is granted to a logged in user; there is no governance unless this is done. Right now, registry maintenance supported via messages is able to leverage the authentication and authorization capabilities of the Interoperability Layer. Some of the registries, however, don't (today) support message-based management; they have their own UIs. If, for these registries, the user community is small and the "traffic" is small, then a simple "remote screen" solution (over VPN) might suffice. If the user or the traffic will be high, it seems a better solution to leverage the Interoperability Layer's centralized authentication and authorization capabilities.

My $0.02...

DJ

[Ryan Crichton]

Thanks Derek, this pretty much mimics the discussion that we had on the Interoperability Layer call yesterday. So just to summarise, here is what I understand us to be saying:

• The PR should host a single sign-on authentication mechanism for human users interacting with the registries maintenance UIs.
• The Interoperability Layer should use ATNAs node authentication for authentication of client systems - this uses PKI.
• For authentication of transactions, the Interoperability Layer should check the human user responsible for that service request and check the PRs authentication service to ensure that that human user is allowed to perform that transaction before sending that transaction on to other registries.
• Other registries don't need to know about the individual human users that is responsible for the service request as the Interoperability Layer will only communicate with these registries using a pre-defined service user.

Let me know if this is your understanding as well, else please edit this list with your changes and we can iterate over it.

Cheers,

Ryan

--

You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Derek Ritz]

Hi Ryan.

I know I must be starting to sound like a broken record, but I really do believe we need to separate out authentication from authorization and be sure to use these terms precisely. For this reason, I think I'd express your 4 points slightly differently:

• The PR should maintain the authorities for human users; these are the permissions and access control attributes which may be associated with an EPID (enterprise provider ID).
• The IL should employ ATNA to authenticate nodes on the eHealth network (using PKI). It is the responsibility of POS applications at these nodes to authenticate human users using whatever mechanism is appropriate; and the IL will trust this authentication.
• eHealth transactions may only be submitted to the IL via authenticated nodes. The ID of the human user is conveyed as part of each eHealth transaction; this is the provider ID, which will be resolved to an EPID by the IL. As part of the EPID resolution, the IL will fetch this user's authorities from the PR. These authorities may be employed by the IL in its transaction processing logic (e.g. ensuring that a PRE, prescription, transaction is being submitted by an EPID that has authority to prescribe and throwing an exception otherwise).
• Ideally -- registry maintenance transactions will employ the IL (for node authentication) and the PR (for user authorization) as described above. This implies that registry maintenance applications will be able to separate their UI from their transaction processing. Any registry maintenance application which cannot do that should adopt a "console application inside the datacentre" kind of posture and ensure its authentication, authorization and audit logging meets the same high standard of security as the IL/PR would have enforced.

This 4th point was the crux issue on the Architecture Community call. The gist, I think, is that we should look for our registry maintenance applications to satisfy all the criteria to be a "trusted application" just like any other POS needs to do. One way for them to do this is to employ the same PKI and user authority mechanisms as the rest of the POSs on the network. This is, I think, preferred -- but it will mean the IL will need to expose registry maintenance transaction connectors (add/update client, provider, location, etc.). We have IHE profiles which do most of these things (PAM for clients; HPD for providers), but not all. This is a gap we should work to close.

Another key point, I think, is that POS applications authenticate users and the IL authenticates nodes (using ATNA). One of the things we haven't talked about at all is the concept of an application ID. In our web of trust, if we're going to believe that any application at a trusted node is able to authenticate its users, we maybe should have some way to know which application is submitting the transaction (since there may be multiple applications running on a single server, and therefore sharing a single PKI certificate). AppID may be in our future as an element of each submitted transaction.

DJ

[Ryan Crichton]

Hi Derek,

Thanks for the expansion, you are saying the same thing as me in most of these points except for the 4th point.

For the 4th point I'd be interested in hearing what the other registry owners have to say as it affects them directly. I'm not sure how practical it is to have the communication between a registries UI and its service to travel through the interoperability layer. There are likely many, many more API call that are necessary to manage the a registry service and to display a good UI than are nesseccary to interact with the service in an interoperable fashion. It seems to makes sense to me that the management UIs are deployed alongside the registries as long as appropriate auditing and access control is in place. I'm interested in hearing what other think.

Cheers,

Ryan

[Carl Leitner]

Hi All,

Please forgive the cross-posting, but I believe that the discussion below has a lot of relevance to the members of our provider registry community, in both as sources and consumers of provider data.    

For the PR community, below is a discussion on using a PR to centralize authentication information.   We would appreciate your feedback.

Cheers,

-carl 

[Derek Ritz (ecGroup)]

Hi Carl.

 

I know I’m like a dog with a sock regarding this point, but I believe the thread is discussing how the PR would enable us to centralize authorization information… but not authentication information.

 

Sorry for being such a stickler on this point.

 

Derek.

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

--
You received this message because you are subscribed to the Google Groups "Provider Registry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to provider-regis...@googlegroups.com.

[Carl Leitner]

Hi Derek,

I did mean to put "authentication and/or authorization" in my message, as I was not trying to pre-conclude any discussion.  My apologies on that.    

I would appreciate feedback from the larger PR community as to the exact functionality that the PR would be likely to be asked to to expose.

Cheers.

-carl

 

On Oct 16, 2013, at 2:04 PM, "Derek Ritz \(ecGroup\)" <derek...@ecgroupinc.com> wrote:

Hi Carl.

 

I know I’m like a dog with a sock regarding this point, but I believe the thread is discussing how the PR would enable us to centralize authorization information… but not authentication information.

 

Sorry for being such a stickler on this point.

 

Derek.

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments. 
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

 

From: provider...@googlegroups.com [mailto:provider-regi...@googlegroups.com] On Behalf OfCarl Leitner
Sent: October 16, 2013 12:20 PM
To: ohie-arc...@googlegroups.com; Provider Registry Google Group
Subject: Re: Authenticating and authorizing service account

 

-- 
You received this message because you are subscribed to the Google Groups "Provider Registry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to provider-regis...@googlegroups.com.

[Bob Jolliffe]

Sorry I haven't been part of the detailed earlier conversation.  But I do wonder at the wisdom of this scope creep of the provider registry acting as a centre for authorization information.  How would this square with, for example, the widespread prevalance of windows domain controllers and the like.  Will PR also provide those functionalities?  I'd guess probably not, but then we are also faced with the possibility of quite some overlap.  Though I am in favour of HR department managing authorization and user identity in general this idea needs to be sold into the real world with often existing infrastructure and processes.  I have been involved in efforts to remove ActiveDirectory from gov departments and can confirm it is really difficult. 

I also see a  creeping assumption of some kind of PKI infrastructure.  This is a need I also identified a year or two back in Rwanda, but the fact is it is a pretty hard thing to get right (I have had the mixed pleasure of implementing PKI in a government department) and adds quite a level of complexity to the skill-set requirement for system managers.

I suspect in both of these cases (and probably a few more) we really need some sort of maturity model which might include OpenHIE Tier 1 as the basic kit with the minimum complexity, moving through increasing levels of sophistication before reaching the deluxe model.

Bob

[Carl Leitner]

Hi Bob,

To give some context, one of the original motivations for this question was around the OpenMRS Provider Module that will be deployed in Rwanda.   

The idea with this module, as I understand it,  was to allow OpenMRS to provide basic provider information from the PR to link with user information.  In this context, I think it is a natural question to ask if the OpenMRS Provider Module should also be able to request authentication and/or authorization information from the PR.

As I don't know the full use cases/needs here, I would invite the OpenMRS group to add in their $0.02.

Cheers.

-carl

On Oct 16, 2013, at 2:36 PM, Bob Jolliffe <bobjo...@gmail.com>

 wrote:

[r.fri...@mindspring.com]

My understanding from our call was that: (1) within the data center, a registry's maintenance application would handle authorization for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry's maintenance application. 

We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address only deep sysadmin functions.

I am still concerned that this is not flexible enough to accommodate role assignments within the facility.  For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time).  Suppose one authority for the emergency room triage nurse is to access a patient's records at another facility without patient consent.  A nurse might be brought in from another facility to cover for a missing triage nurse, and we don't want to have to do a personnel reassignment before she starts. Or the Head of Nursing might cover and we don't want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.

[Derek Ritz]

I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority -- it is entirely untenable to try to establish a definitive circle of care in each clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription) transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider "type". In the case of a PRE transaction, the IL might process all inbound transactions where provider type in ["physician", "nurse practitioner"] and throw an exception otherwise. (I know this isn't proper WHO-conformant type coding, but you get the idea). ;-)

As another point, the "identity" of a nurse doesn't change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however, RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).

This is not an easy topic. I hope this PPT helps.

Derek.

[Ryan Crichton]

Thanks Derek, that slideshow is a great resource. What you have portrayed there is also my understanding of what we have been iterating towards.

I've added your slideshow to the wiki page on the design of the interoperability layer: https://wiki.ohie.org/display/SUB/OpenHIE+Interoperability+Layer+design+document. I will continue to update this page as these discussions continue.

Cheers,

Ryan

--
You received this message because you are subscribed to the Google Groups "Provider Registry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to provider-regis...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

[Hannes Venter]

Derek, I do think that it would be beneficial to try and look at finer-granularity at the HIE level, specifically when it comes to the SHR.

I'm sure we'll run into use-cases where we need to be able to say "entity A should only be allowed access to documents of type X".

It seems to me that various IHE profiles are very well catered towards the handling confidentiality/privacy-consent at a document-level, and I think it'd be good to try and make use of this.

(XDS for example specifies that a confidentialityCode field needs to be specified in the document metadata).

Finer granularity would fit in with the model outlined in the slides I think: I can imagine a scenario where we allocate confidentiality/permission codes at a provider level

and have the IL enforce it for queried documents from the SHR (rather than at the transaction level).

Not to imply that this would be an alternative to transaction level restrictions, generally speaking, but in addition to it.

Just a $0.01 to add to the discussion :)

Cheers

Hannes

--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Hannes Venter

Software Developer, Jembi Health Systems |  SOUTH AFRICA

Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: han...@jembi.org

[Ryan Crichton]

Hi Hannes,

I agree. When I've been thinking of authorities in the PR I think we have have these at multiple levels of granularity depending on implementation needs. It also gives us a maturity model as we more from simple authorities to more complex/granular authorities as time goes on.

My $0.0001 :)

Ryan

[r.fri...@mindspring.com]

Thank you Derek for such a well-considered response.

The idea that PoS interactions with the registries are through pre-defined transactions, and that authorities are for particular transactions, is I think right in an engineering sense.  We would have to adopt existing types of transactions and/or create a transaction definition capability, as well as a transaction-vetting and -curation organization (perhaps at the national level).  Standardizing transactions can take a lot of time.  The ONC Continuity of Care Document definition process addresses what I think is a core function for the SHR and AFAIK has no concrete output.  To succeed, there would have to be more rigorous business process analysis and willingness to change (or maintain) existing procedures, and do this on a timely basis, than we are used to.

Our primary PoS and registry products, OpenMRS, DHIS2 and iHRIS, are data- not transaction-oriented, and a transactional mechanism would have to be added.  For OpenMRS, the transaction would be something between an encounter and a visit (since encounters are becoming more fine-grained as they are made more specific to facility workflow, while visits are too coarse-grained for inpatient records).  HL7/CDA would provide a transport protocol.  For DHIS2 and iHRIS, the transactions are more easily identified, but AFAIK there are no standard datasets or vocabularies.  Nor am I aware of standard protocols for the exchange of facility or HR data which encompass the full range of transactions.  Certainly if we put permissions in the PR, we will be rolling our own message.  This work would have to be funded.

This architecture takes us away from our experience.  From what Ryan has been saying, I take it that the Rwanda SHR is pretty much one-to-one with the facility's EMR.  And the most developed HIEs involve lab results, which have few transaction types and disease-or-condition program-related issues.  I don't see an incremental way of moving from what we have to Derek's approach. 

Perhaps we should reconceptualize the registries as data warehouses rather than active transactional DBs.  The IL would become a collection of PoS application-specific ITL (import/translate/load) processes operating on exported datasets to extract pre-defined analytical datasets.  Each of these analytical datasets could be exported in a PoS application-specific way at the granularity of and containing data in the analytical dataset.  The analytical datasets could be de-identified or aggregated and made available to AVR software.  There would be no human users of the data warehouses and the only type of human request to the IL would be to provide an export file containing particular analytical datasets filtered by user-defined criteria in PoS format to particular authenticated PoS instances.  Authenticated PoS application instances would be able to make similar requests through a SOAP- or REST-based interface with data returned in native or XML/JSON format.  The analytical datasets and PoS formats could be defined incrementally, and new dataset ITLs could process retained PoS files to collect history.

-----Original Message-----

From: Derek Ritz
Sent: Oct 16, 2013 11:01 PM
To: ohie-arc...@googlegroups.com
Cc: Provider Registry Google Group , r.fri...@mindspring.com
Subject: Re: Authenticating and authorizing service account

[r.fri...@mindspring.com]

Derek, it appears your comment missed the list.  I don't want to get engaged in a back-and-forth before others have the opportunity to reply, but I do want to clarify what I meant by "primary PoS and registry products."  It is my understanding that these 3 products represent our current registry implementations and that these 3 open source projects are the ones who have agreed to collaborate towards OHIE.  I could be wrong about this.

-----Original Message-----
From: Derek Ritz
Sent: Oct 17, 2013 3:59 PM
To: r.fri...@mindspring.com
Subject: Re: Authenticating and authorizing service account

Hi Roger.

You have raised a number of important (and insightful) issues. Let's pace thru them. First -- you are completely correct that, if we are going to leverage the IL and PR in the way that is contemplated in the PPT, we will need to have transactions that operationlize registry maintenance. There are IHE profiles (e.g. PAM for client registry, HPD for provider registry, CTS for terminology maintenance) that do this. Although there are OMG and HL7v3 transactions for doing facility registry maintenance, there is not (presently) any IHE profile. This is a gap... and perhaps an opportunity.

I think it is dangerous to refer to OpenMRS as our primary PoS product. The fact that it is the only one we are presently connected to should not imply that OpenHIE is "designed for OpenMRS" as its PoS. To do so would fundamentally undermine the HIE's value proposition as an integration and sharing infrastructure. On the registry and repository side, it is fairer to say that we leverage "HPD" than that we leverage iHRIS and, as things evolve, it may be more accurate to say we're leveraging CSD than DHIS (or Resource Map) and XDS more than OpenMRS (as our SHR, in this case). These interfaces allow different products to be employed as our repositories and registries and in every case, the transactions are what are conformance testable. Our adoption of these, except for HPD, is still pretty nascent -- but I think that is the stated direction as we move forward. To be clear, though, employing the PR for authorization is really going to be more about leveraging provider attributes in our IL orchestration than about setting "access rights". As is noted in IHE's HIE white paper (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf) "HPD does not support attributes intended directly for Access Control".

Roger, you say that this architecture, by which I assume you mean the OpenHIE architecture, takes us away from our experience. This may be true. So far, at least, our experience in Rwanda has largely been to share OpenMRS PoS information using an OpenMRS SHR. I would contend, however, that this is because we are early in the evolution of this infrastructure -- not because that is all the infrastructure is designed to do. I don't share the view that we need to fundamentally rethink how our puzzle pieces operate or how they fit together. In fact, some of our most crucial puzzle pieces (IL and SHR) will really start to come into their own as our use cases and our edge nodes grow and evolve from the ones we started out with. We are also, only now, starting to embrace the PoS interface standards that will lead to system-to-system interoperability supporting continuity of care. This will be, I think, quite a bit less daunting and significantly more scalable than the PoS-specific ITL engine you describe in your last paragraph (below).

The crawl, walk, run strategy was not an unsound one... and it doesn't mean that all our HIE knows how to do is crawl... ;-)

Thanks, Roger, for asking probing questions and for raising the level of the discourse!

Warmest regards,

Derek.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-architecture/NfWkWVcywjM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ohie-architect...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Derek Ritz
----------------
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Derek Ritz]

Thanks, Roger. I didn't realize I'd not replied-all. Re: the collaborators on OHIE, the list is larger than those 3 and growing -- but you correct that those are certainly "pillars" of the community. :-)

[Ryan Crichton]

Thanks Derek for those comments on the use of standards.

It seems that using the PR to hold authorization information is a good option and I haven't heard much to state otherwise. @Carl L, it would be great to hear your thoughts on this.

Also, on the topic of standards, it would be great if this group could start thinking around the functions that each registry should make available and that are need when the OpenHIE architecture is deployed as a whole. In this case the components will need to be able to cooperate. I have started putting together a diagram to try show what these could be. This is a different topic though and I will start another thread where we can discuss this further.

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

[Carl Leitner]

Hi Ryan,

This is fine with me.  It seems like we have a consensus.   

Perhaps a next step is to define exactly how the authorization information is going to be kept in the Provider Registry / CSD data model.   There are extension points built into CSD we can take advantage of.  Something like:

<CSD>

    <providerDirectory>

        <provider oid='2.25.1231231232112328988979888312321321'>

             <extension type='authorization' oid='2.25.309768652999692686176651983274504471835'>

                <!-- DETAILS ON AUTHORIZATION GO HERE-->

            </extension>

       </provider>

   </providerDirectory>

</CSD> 

There are two oids here.  The first is the "enterprise provider ID" if you like.  It is unique for each provider in the directory.

The second is for the extension point.  I would suggest that we put all "OpenHIE"  extensions to CSD (whether for provider, facility, etc.)  under extensions point with the same OID.  The one I generated above, 2.25.309768652999692686176651983274504471835, comes from the UUID e90b45c0-3b1c-11e3-a7c6-0002a5d5c51b according to the rules:

  http://www.itu.int/ITU-T/asn1/uuid.html

for representing UUIDs as OIDs 

For the type='authorization'  we have some flexibility here on how to best use the type attribute, as well as in defining the <--DETAILS ON AUTH-->.   I assume that we need some back and forth on deciding the best way to represent authorization for a provider.

So this brings up a few documentation and process related issues:

• How do we document the details on authorization and any other extensions to CSD we agree to use as the OpenHIE community.  Wiki?  Github or other VCS?  Some combination of these?
• What is the modality for having this detailed conversation? In that the details above are probably of interest only to a small segment of the ohie-architeture and provider-registrty google groups, are these groups the correct place to get into this level of detail?  If not, how should we best do this?

Cheers,
-carl

[Paul Biondich]

After reading through this thread, I'm left with a few questions/observations:

1)  I think we should be clear on what we mean by "human users".  There are human users of the tools/management applications that sit within/above the HIE and human users of the nodes that connect to the HIE.  I'm pretty sure we agreed that nodes should be left to their own human user authentication, and that we also agreed that HIE management applications could very well manage their own human user authentication, but that we could explore a maturity model that'd include provider registry based central authority for management application user lists.  Do people agree with this?

2)  There's a presumption in the thread that for "nodes" to access the HIE, that they need to be authenticated via PKI.  My gut instinct is that we should certainly be open to such models of authentication, but not enforce/mandate them.  There are a whole bunch of other models of authentication I've seen used in real world circumstances (ie, IP/MAC address based authorization, tokens, simple user/pw) that work in real world settings.

3)  I think it's worth exploring whether registry "maitenance applications" are any different than nodes below the network.  I think they likely are, but Derek brings up a good point.  Is this a useful distinction, and as such... do they get a "different interaction rule set"?

-Paul

[Ryan Crichton]

@Carl L, that sounds promising. I'd be keen to explore that more. Perhaps using a github repo and github issues like for the FRED api would work well for that level of technical detail? I think we will need to start writing up the general concepts that we are agreeing to in this thread on the wiki as well to ensure everyone is on the same page.

@Paul, here are my responses to your observations:

1. What you have described for human users is my understanding as well. We have moved on to discussing the service user interactions. In these cases when system are talking to other systems we need to make sure the provider referenced in the message has the correct authority to perform the action they are requesting. The PR can hold this information. Derek was suggesting that this could be as simple as making sure the provider is valid and checking that they have the correct role to perform that action (ie. nurse, doctor, pharmacist).
2. The reason why PKI has been suggested and is the leading approach is because that is what the NA - Node Authentication - part of the ATNA profile specifies. As we are trying to be supportive of IHE profile it seems to be best option.
3. I think ideally these should be nodes below the network but I'm not sure how practical this would be as the maintenance application would likely need more comprehensive access to adding and modifying the data. I don't think the standards are comprehensive enough to allow for this so it seems to make sense to more that the maintenance applications should be allowed to communicate directly with that registry's data store.

Cheers,

Ryan

[Scott Teesdale]

Hi All,

I wanted to pass along a few notes from our dev team and share some of the scenarios currently unfolding with the Tanzania implementation of the FR that I think can point to larger patterns in OHIE about how we handle authorization and authentication.   

Tanzania is really proving as a good example currently as there are now local developers actively writing apps against a service (e.g., UIs for data maintenance and curation workflows). We have separated these aspects from the facility registry and implemented them from the FR perspective; so we now have a FR that has 'torn off' that functionality working well in staging, the Tanzania group effectively comfortable coding to an external 'authentication authority' which is neither their code nor the FR. So in terms of "red, green, refactor" we have the first two stages and this now seems to be a perfect time to see how to merge it w/ this dialogue.

As a result of this in TZ we are moving forward with the:

• Implementation of OpenID as an AuthN authority.
• Implementation of different oAuth 2.0 workflows to allow delegated or "service accounts" from trusted apps (any app that uses the service account pattern has to be trusted/whitelisted (as so) as it implies it won't abuse the privileges of that account). Still working on the more common permission granting oAuth mechanism though (for example).

One next step we are interested to discuss and see evolve is how the Provider Registry can drive the authentication authority (e.g., specifically debating whether the relationship between a PR and an authN authority is a "IS A" or "MANAGES A").  Could we include this as a topic in the next architecture call? I would be happy to arrange for some of our devs to give a more in-depth summary of these updates as well. 

Best,

Scott 

*** Ed, Nico, Martin, feel free to jump and add any other relevant details or clarifications as well. 

Scott Teesdale

Project Manager - InSTEDD

Email: stee...@instedd.org 

Skype: scott.teesdale 

Social: Twitter / LinkedIn 

[Derek Ritz (gmail)]

Hi Scott. 

Did the team get a chance to look at the IHE profile for this? Sorry...don't remember what it's called, but it completed ballot last year and profiled the use OAuth in a healthcare setting. The authors of the profile are engaged with the OAuth development group somehow.

DJ 

Sent from my iPad

[Scott Teesdale]

Hi Derek, 

I would venture to say we haven't looked into it closely enough given our relatively recent engagement with IHE.  If you have any links for that profile or contact details for those involved they could be helpful as we move forward. 

Best,

Scott   

[Eduardo Jezierski]

Hi - you mean ATNA? 

I have, and looks promising. We are starting with the User authentication area -  as the audit trail is a relatively easier issue and cert-based 2 way authN between nodes is also a common practice for the few select 'super trusted services' living in the HIE.

We want to implement a mechanism that shows it is compatible to use web standards (oAuth, OpenID) with ATNA. ATNA does not mandate a user authentication approach, and therefore things like oAuth (which is a standard for delegated user authentication) would fit in as well. 

After that, the audit trail (which shows up as an "activity stream" in resmap) can be refactored into the same service.

I would love it if we can contribute this work into the HIM package.  It has already shown immense value working in Tanzania where a local company is doing their own tool to manage the data curation, approval and edition process and they have been able to do this without managing an alternate set of users, permissions, etc. 

For the node to node authentication between HIE components, the HIM could include an admin tool that simplifies the certificate request and deployment process needed the profile. sysadmin tools that do this are common, but having a "how to" guide to make sure the SSL  connections between the components are 2 way authenticated may come in handy for LMICs. 

~ ej

[Ryan Crichton]

Hi all,

I think the profile that Derek is referring to may be this one: http://wiki.ihe.net/index.php?title=Internet_User_Authorization

It is great to hear that the Tanzania work has provided some real needs for this discussion. I'd love to talk about this in more detail and hear what you guys are planning to implement.

@Ed, It would be great if you could contribute some of this work to the OpenHIM. How exactly do you see this being included in the OpenHIM? How would oAuth work in this case? Would the OpenHIM provide the authentication service?

I agree that the HIM could provide a simplified UI to generate and manage certificates for managing mutual TLS connections. We've been thinking about this a little bit as well internally at Jembi. It seems like a good area that could benefit from some simplification for LMIC.

Cheers,

Ryan

[Eduardo Jezierski]

Ryan - 

Of course!  we need to coordinate a dev meeting to see what are the projects, the shared needs and how things could be packaged and contributed into the HIM.

Re. TLS in LMICs; as an example we have over a thousand TLS secured connections going into clinics around South Africa connecting them to the cloud right now as we speak; all of those were provisioned by a simple opt-in from end users with no tech knowledge. So from there to having a simple tool for sysadmins should it be a much simpler job and probably one that there's plenty of open source toolkits to start from.

Maybe Scott and Martin can propose some times that work to have that call (im out next week)

~ ej