Authenticating and authorizing service account

ryan · October 15, 2013, 11:36am

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: ryan@jembi.org

Burke_Mamlin · October 16, 2013, 12:23am

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

···

On Tue, Oct 15, 2013 at 7:36 AM, Ryan Crichton ryan@jembi.org wrote:

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: ryan@jembi.org

–

–

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-architecture+unsubscribe@googlegroups.com.

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

derek.ritz · October 16, 2013, 3:27am

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

···

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

ryan · October 16, 2013, 9:35am

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

···

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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-architecture+unsubscribe@googlegroups.com.

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

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

derek.ritz · October 16, 2013, 12:04pm

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

···

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

ryan · October 16, 2013, 1:40pm

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

···

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ry...@jembi.org

–

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-architecture+unsubscribe@googlegroups.com.

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

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

Carl_Leitner1 · October 16, 2013, 4:19pm

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

···

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ry...@jembi.org

–

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-architecture+unsubscribe@googlegroups.com.

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

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

dritz · October 16, 2013, 6:04pm

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-registry@googlegroups.com [mailto:provider-registry@googlegroups.com] On Behalf Of Carl Leitner
Sent: October 16, 2013 12:20 PM
To: ohie-architecture@googlegroups.com; Provider Registry Google Group
Subject: Re: Authenticating and authorizing service account

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

On Oct 16, 2013, at 9:40 AM, Ryan Crichton ryan@jembi.org wrote:

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

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–
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.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
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-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Carl_Leitner1 · October 16, 2013, 6:10pm

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.ritz@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-registry@googlegroups.com [mailto:provider-registry@googlegroups.com] On Behalf OfCarl Leitner
Sent: October 16, 2013 12:20 PM
To: ohie-architecture@googlegroups.com; Provider Registry Google Group
Subject: Re: Authenticating and authorizing service account

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

On Oct 16, 2013, at 9:40 AM, Ryan Crichton <ryan@jembi.org> wrote:

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

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz <derek.ritz@gmail.com> wrote:
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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:
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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz <derek...@gmail.com> wrote:
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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:
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

--
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.

--
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

--
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-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

--
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-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

bobj · October 16, 2013, 6:36pm

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

···

On 16 October 2013 19:10, Carl Leitner litlfred@gmail.com wrote:

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.ritz@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-registry@googlegroups.com [mailto:provider-registry@googlegroups.com] On Behalf OfCarl Leitner

Sent: October 16, 2013 12:20 PM
To: ohie-architecture@googlegroups.com; Provider Registry Google Group
Subject: Re: Authenticating and authorizing service account

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

On Oct 16, 2013, at 9:40 AM, Ryan Crichton ryan@jembi.org wrote:

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

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.

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

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.

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

–
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-registry+unsubscribe@googlegroups.com.

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

–

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-architecture+unsubscribe@googlegroups.com.

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

Carl_Leitner1 · October 16, 2013, 6:49pm

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 16 October 2013 19:10, Carl Leitner litlfred@gmail.com wrote:

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.ritz@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-registry@googlegroups.com [mailto:provider-registry@googlegroups.com] On Behalf OfCarl Leitner

Sent: October 16, 2013 12:20 PM
To: ohie-architecture@googlegroups.com; Provider Registry Google Group
Subject: Re: Authenticating and authorizing service account

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

On Oct 16, 2013, at 9:40 AM, Ryan Crichton ryan@jembi.org wrote:

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

On Wed, Oct 16, 2013 at 2:04 PM, Derek Ritz derek.ritz@gmail.com wrote:

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

On Wednesday, October 16, 2013 5:35:19 AM UTC-4, Ryan Crichton wrote:

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

On Wed, Oct 16, 2013 at 5:27 AM, Derek Ritz derek...@gmail.com wrote:

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

On Tuesday, October 15, 2013 7:36:25 AM UTC-4, Ryan Crichton wrote:

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

–

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.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.

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

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

–
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-architecture+unsubscribe@googlegroups.com.

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

–
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-registry+unsubscribe@googlegroups.com.

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

–

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-architecture+unsubscribe@googlegroups.com.

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