I just wanted to bump this email up as some people where not aware that I sent the original email to the architecture list. Here is the original contents:
···
On Thu, Sep 26, 2013 at 3:35 PM, Carl Leitner litlfred@gmail.com wrote:
Hi Ryan,
I haven’t really dug into what ATNA requires (it’s not required for CSD and I haven’t looked at the other profiles where it is required) so that’s probably why my question didn’t make much sense 
It is with the first part (audit messages) that I was wondering about and you have answered that.
This seems to answer the second part on web-services + ATNA discussion for security:
http://wiki.ihe.net/index.php?title=ATNA_Profile_FAQ#Why_doesn.27t_ATNA_use_Web-Services_Security.3F
Cheers.
-carl
On Sep 25, 2013, at 3:00 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
The OpenHIM does support ATNA for some of the IHE profiles transaction that we support (PIX and XDS.b). ATNA describes 2 things, how audit messages are sent to an audit repository for transactions and seondly how communication is secured between nodes using PKI. I don’t think there is any alignment between ATNA and WSDL ports, but there may be for some specific profiles. When you say align access control with ATNA audit events do you mean firing off access control checks at a similar time to when audit messages are sent or something different?
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Mon, Sep 23, 2013 at 3:57 PM, Carl Leitner litlfred@gmail.com wrote:
Hi Ryan,
Yes the port sounds does sound right.
That being said, from what I understand OpenHIM supports the ATNA IHE. I haven’t dug into ATNA, but do you know if there is there any alignment between ATNA and WSDL ports? If possible, it may be a good idea to align access control with ATNA Audit Events.
Cheers.
-carl
On Sep 23, 2013, at 3:10 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
Sorry for the delayed response. Thanks for this. It sounds like something that we should look into. I like you suggestion. I will create a wiki page to capture your suggestions and we can start to work something out. I’ve created a basic page here: https://wiki.ohie.org/display/SUB/Restricting+access+to+domain+service+endpoints. How do you see a WSDL or WADL working. Would the Interoperability Layer import these and recreate these services and proxy those. And in doing so be able to restrict access to the services by, for example the port of the WSDL or something similar?
@All, before we get to some of the specifics of how the architecture works, how does this overall architecture sit with everyone? Does everyone think this would be a good model to follow? We are open to hear any and all opinions about this. @Ed, any specific points you would like to add about the overall architecture?
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Thu, Sep 19, 2013 at 3:00 PM, Carl Leitner litlfred@gmail.com wrote:
Hi Ryan,
While URL pattern matching would certainly work for me, and while I don’t have any particular preference, I do think it is worthwhile to look at existing standards for making all these services known and to keep the software components as “pluggable” as possible.
I know WSDL has a bit extra overhead, but it may be worthwhile as consideration. Perhaps it’s time for a spreadsheet to compare the pros/cons of different options e.g:
- URL pattern matching
- WSDL 1.1
- WSDL 2.0
- WADL
- any others?
against something like:
- existing libraries (Java, Python, PHP, etc)
- related security models/access control mechanisms
- supported “transport” mechanisms
- proxy/pass-through
- support for REST verbs
- compatibility with proposed inter-operabiltiy layer architecture
- compatibility with other IHE profiles
- etc.
Cheers,
-carl
On Sep 19, 2013, at 2:58 AM, Ryan Crichton ryan@jembi.org wrote:
Hey Carl,
None of this is set in stone, but yes I’d imagine that we could have different privileges for different URL paths. Do you think this would work for you or can you think of a better way?
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Wed, Sep 18, 2013 at 3:25 PM, Carl Leitner litlfred@gmail.com wrote:
Hi Ryan,
OK. Trying to understand how this ties into “Authorization and Authentication service,” in this example, would this mean the privileges would be evaluated on the service domain level (e.g. the provider registry) based on the URL pattern?
So, if I am understanding, if we wanted to maintain distinct sets of privileges for several services in a domain (e.g. “search for a provider”, “update provider information”, etc.) then we would need to setup a separate URL pattern for each of these?
Just as an aside, in CSD the communication between the “Info Manger” and “Services Directory” actors is via SOAP with an accompanying WSDL.
Cheers.
-carl
On Sep 18, 2013, at 9:12 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
I have through around this a bit and I have been thinking of something even simpler. Just proxying requests with a specific URL pattern (say /api/providerregistry/*) and sending them to a specific configured domain service (so in this example the provider registry).
So basically just acting as a proxy to the domain services.
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Wed, Sep 18, 2013 at 3:01 PM, Carl Leitner litlfred@gmail.com wrote:
Hi Ryan,
Thanks for this. You mentioned a potential dependency know that “could be mitigated by allowing simple pass through of web services via configuration.”
Have you given any thought about how this will be defined, for example, by requiring the domain services to provide a WSDL(or WADL or what have you) to expose their endpoints?
Cheers.
-carl
On Sep 18, 2013, at 5:28 AM, Ryan Crichton ryan@jembi.org wrote:
Hi all,
We began to discuss the role of the interoperability layer and how this should work to connect the services of OpenHIE on the first architecture call. I’d like to continue this discussion in this email thread. Below is a link to the current thinking that the Interoperability Layer group has be working towards.
https://wiki.ohie.org/display/SUB/OpenHIE+Interoperability+Layer+design+document
The interactions that we anticipate to be managed by the interoperability layer are those between the clients systems and services of the HIE. Each service or registry may also have a user interface that users can access directly. So, what we are really considering in this design is how systems exchange information and not how users access the user interface of the services or registries.
@Ed, I’d be particularly interested in hearing if this is congruent with your thinking.
Please let me know what you think and how we can change this design to better reflect what the OpenHIE communities think is best.
Thanks all.
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.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org