I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
On 19 February 2014 14:59, Ryan Crichton ryan@jembi.org wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
···
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
@Hannes, thanks for picking this up. I agree completely we should allow someone to upload a certificate if they already have one. I had this in my mind but didn’t represent it in the workflow. I will change it.
I believe for web applications (which pretty much all the OHIE application are) you would just be able to use apache or similar in front of the web app to allow it to use HTTPS. But, you are right we should explore this further because I’m not quite sure on this.
Agreed, but the HIM will set this up based on the certificates that it generates/receives but you are right once it is setup it just works at the transport layer.
Yes, the intention here is that there are times where we will need to inspect the message contents to be able to determine if a particular application has the authority to send this type of message. A concrete example of this is for the HWR workflows where a provider’s details need to be updated, the uuid of the function in the message much be checked to see what type of function this is so that the authority of an application to invoke that function may be checked. In this case knowledge of the message is required, thus it should be handled by a message specific orchestrator. I agree, having an RBAC actor in our clear box seems like a good approach to make this sort of thing simpler. Are you suggesting that we add an ‘IL RBAC’ actor to this diagram to show this more clearly?
Thanks for the comments guys, they have been very helpful. Keep them coming.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
RE: my question #2 – I wasn’t as concerned about what we’ll do at our side, I was thinking about what mechanism we can employ to enforce that there will be one and only one application on the POS side that is using a certificate. Like I said, certificates tend to be installed at the OS level (or at the login user level), which would potentially enable ALL applications installed on a POS-side server to use the TLS pipe. I’m not
sure how we would lock down the POS side to only allow ONE application to use the TLS pipe.
RE: #4 – yes, I definitely think our “clear box” diagrams should explicitly show all kinds of IL “sub-elements”. RBAC is definitely one that deserves a place; and I think CDMS does, too.
Further to our “clear box”, I’ve attached a PPT from Infoway circa 2005 or so – about the time that the blueprint was being socialized within the technical communities in Canada. I’d recommend a look at the whole deck (it’s not a long read, really), but especially around slide 65 there is a bit of a breakdown into the “clear box” of the working elements of the architecture. Things have evolved since this
deck was made so this isn’t actually a definitive example of the present Infoway design… but it provides, I think, a very useful insight into the thought processes that went into the SOA design.
Warmest regards,
Derek.
PS: this and
other stuff is all freely available on the Infoway site. There is also the full set of ALL of Infoway’s design docs that was donated to the HEAL when it was set up in 2010… although I’m sure those pig-o-bytes of data are all archived somewhere by now.
···
On Friday, February 21, 2014 2:05:46 AM UTC-5, Ryan Crichton wrote:
Hi guys,
@Hannes, thanks for picking this up. I agree completely we should allow someone to upload a certificate if they already have one. I had this in my mind but didn’t represent it in the workflow. I will change it.
I believe for web applications (which pretty much all the OHIE application are) you would just be able to use apache or similar in front of the web app to allow it to use HTTPS. But, you are right we should explore this further because I’m not quite sure on this.
Agreed, but the HIM will set this up based on the certificates that it generates/receives but you are right once it is setup it just works at the transport layer.
Yes, the intention here is that there are times where we will need to inspect the message contents to be able to determine if a particular application has the authority to send this type of message. A concrete example of this is for the HWR workflows where a provider’s details need to be updated, the uuid of the function in the message much be checked to see what type of function this is so that the authority of an application to invoke that function may be checked. In this case knowledge of the message is required, thus it should be handled by a message specific orchestrator. I agree, having an RBAC actor in our clear box seems like a good approach to make this sort of thing simpler. Are you suggesting that we add an ‘IL RBAC’ actor to this diagram to show this more clearly?
Thanks for the comments guys, they have been very helpful. Keep them coming.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
For #2: I see, I don’t have a good answer here. Perhaps we will have to have an agreement with the allowed applications doesn’t allow them to do this. Using the multiple certificates on separate servers is even possible so this problem already exists. I guess that we have to trust the owners of the PoS applications to manage their infrastructure properly just as we trust them to authenticate users properly. I’m open to suggestions.
For #4: Ok, that is what I thought. It sounds like a good idea to me. I’l update the docs.
RE: my question #2 – I wasn’t as concerned about what we’ll do at our side, I was thinking about what mechanism we can employ to enforce that there will be one and only one application on the POS side that is using a certificate. Like I said, certificates tend to be installed at the OS level (or at the login user level), which would potentially enable ALL applications installed on a POS-side server to use the TLS pipe. I’m not
sure how we would lock down the POS side to only allow ONE application to use the TLS pipe.
RE: #4 – yes, I definitely think our “clear box” diagrams should explicitly show all kinds of IL “sub-elements”. RBAC is definitely one that deserves a place; and I think CDMS does, too.
Further to our “clear box”, I’ve attached a PPT from Infoway circa 2005 or so – about the time that the blueprint was being socialized within the technical communities in Canada. I’d recommend a look at the whole deck (it’s not a long read, really), but especially around slide 65 there is a bit of a breakdown into the “clear box” of the working elements of the architecture. Things have evolved since this
deck was made so this isn’t actually a definitive example of the present Infoway design… but it provides, I think, a very useful insight into the thought processes that went into the SOA design.
Warmest regards,
Derek.
PS: this and
other stuff is all freely available on the Infoway site. There is also the full set of ALL of Infoway’s design docs that was donated to the HEAL when it was set up in 2010… although I’m sure those pig-o-bytes of data are all archived somewhere by now.
On Friday, February 21, 2014 2:05:46 AM UTC-5, Ryan Crichton wrote:
Hi guys,
@Hannes, thanks for picking this up. I agree completely we should allow someone to upload a certificate if they already have one. I had this in my mind but didn’t represent it in the workflow. I will change it.
I believe for web applications (which pretty much all the OHIE application are) you would just be able to use apache or similar in front of the web app to allow it to use HTTPS. But, you are right we should explore this further because I’m not quite sure on this.
Agreed, but the HIM will set this up based on the certificates that it generates/receives but you are right once it is setup it just works at the transport layer.
Yes, the intention here is that there are times where we will need to inspect the message contents to be able to determine if a particular application has the authority to send this type of message. A concrete example of this is for the HWR workflows where a provider’s details need to be updated, the uuid of the function in the message much be checked to see what type of function this is so that the authority of an application to invoke that function may be checked. In this case knowledge of the message is required, thus it should be handled by a message specific orchestrator. I agree, having an RBAC actor in our clear box seems like a good approach to make this sort of thing simpler. Are you suggesting that we add an ‘IL RBAC’ actor to this diagram to show this more clearly?
Thanks for the comments guys, they have been very helpful. Keep them coming.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
A quick thought here from a high level view and completely unbiased:
What is the real opportunity of us having multiple POS applications on the same machine?
Reason for question: if it is a low probability then we should prob abstract out this case as an assumption; if high then we need to engineer to support this ( can we list out some use cases on the wiki for this?)
Cheers
Carl
···
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail:carl@jembi.org
On Mon, Feb 24, 2014 at 11:00 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Derek,
For #2: I see, I don’t have a good answer here. Perhaps we will have to have an agreement with the allowed applications doesn’t allow them to do this. Using the multiple certificates on separate servers is even possible so this problem already exists. I guess that we have to trust the owners of the PoS applications to manage their infrastructure properly just as we trust them to authenticate users properly. I’m open to suggestions.
For #4: Ok, that is what I thought. It sounds like a good idea to me. I’l update the docs.
Cheers,
Ryan
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
RE: my question #2 – I wasn’t as concerned about what we’ll do at our side, I was thinking about what mechanism we can employ to enforce that there will be one and only one application on the POS side that is using a certificate. Like I said, certificates tend to be installed at the OS level (or at the login user level), which would potentially enable ALL applications installed on a POS-side server to use the TLS pipe. I’m not
sure how we would lock down the POS side to only allow ONE application to use the TLS pipe.
RE: #4 – yes, I definitely think our “clear box” diagrams should explicitly show all kinds of IL “sub-elements”. RBAC is definitely one that deserves a place; and I think CDMS does, too.
Further to our “clear box”, I’ve attached a PPT from Infoway circa 2005 or so – about the time that the blueprint was being socialized within the technical communities in Canada. I’d recommend a look at the whole deck (it’s not a long read, really), but especially around slide 65 there is a bit of a breakdown into the “clear box” of the working elements of the architecture. Things have evolved since this
deck was made so this isn’t actually a definitive example of the present Infoway design… but it provides, I think, a very useful insight into the thought processes that went into the SOA design.
Warmest regards,
Derek.
PS: this and
other stuff is all freely available on the Infoway site. There is also the full set of ALL of Infoway’s design docs that was donated to the HEAL when it was set up in 2010… although I’m sure those pig-o-bytes of data are all archived somewhere by now.
On Friday, February 21, 2014 2:05:46 AM UTC-5, Ryan Crichton wrote:
Hi guys,
@Hannes, thanks for picking this up. I agree completely we should allow someone to upload a certificate if they already have one. I had this in my mind but didn’t represent it in the workflow. I will change it.
I believe for web applications (which pretty much all the OHIE application are) you would just be able to use apache or similar in front of the web app to allow it to use HTTPS. But, you are right we should explore this further because I’m not quite sure on this.
Agreed, but the HIM will set this up based on the certificates that it generates/receives but you are right once it is setup it just works at the transport layer.
Yes, the intention here is that there are times where we will need to inspect the message contents to be able to determine if a particular application has the authority to send this type of message. A concrete example of this is for the HWR workflows where a provider’s details need to be updated, the uuid of the function in the message much be checked to see what type of function this is so that the authority of an application to invoke that function may be checked. In this case knowledge of the message is required, thus it should be handled by a message specific orchestrator. I agree, having an RBAC actor in our clear box seems like a good approach to make this sort of thing simpler. Are you suggesting that we add an ‘IL RBAC’ actor to this diagram to show this more clearly?
Thanks for the comments guys, they have been very helpful. Keep them coming.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
The multiple POS on a single server is very common in hospital environments (where there can be many software programs accessed via a LAN, e.g. EMR, lab, pharma, etc.). It is also found in “hosted” or cloud environments where there is a rack of servers that are collected into a farm… but the “farm” has a single PKI cert and a single IP address exposed to the world.
My sense is that we can, and should, document the assumption plus provide some technical guidance regarding how PKI-cert-per-app may be deployed. I don’t think it is trivial and I do think it will be “different” than what would be the normal/common deployment scenario for many server-based applications.
I’m not expert enough to say definitively, but my gut sense is that we won’t have any way to audit or enforce this deployment configuration. I’m especially not worried about it, though; this is the case for many policy issues.
DJ
···
On Monday, February 24, 2014 4:10:51 AM UTC-5, Carl Fourie wrote:
Hi All,
A quick thought here from a high level view and completely unbiased:
What is the real opportunity of us having multiple POS applications on the same machine?
Reason for question: if it is a low probability then we should prob abstract out this case as an assumption; if high then we need to engineer to support this ( can we list out some use cases on the wiki for this?)
Cheers
Carl
Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail:ca...@jembi.org
On Mon, Feb 24, 2014 at 11:00 AM, Ryan Crichton ry...@jembi.org wrote:
Hi Derek,
For #2: I see, I don’t have a good answer here. Perhaps we will have to have an agreement with the allowed applications doesn’t allow them to do this. Using the multiple certificates on separate servers is even possible so this problem already exists. I guess that we have to trust the owners of the PoS applications to manage their infrastructure properly just as we trust them to authenticate users properly. I’m open to suggestions.
For #4: Ok, that is what I thought. It sounds like a good idea to me. I’l update the docs.
RE: my question #2 – I wasn’t as concerned about what we’ll do at our side, I was thinking about what mechanism we can employ to enforce that there will be one and only one application on the POS side that is using a certificate. Like I said, certificates tend to be installed at the OS level (or at the login user level), which would potentially enable ALL applications installed on a POS-side server to use the TLS pipe. I’m not
sure how we would lock down the POS side to only allow ONE application to use the TLS pipe.
RE: #4 – yes, I definitely think our “clear box” diagrams should explicitly show all kinds of IL “sub-elements”. RBAC is definitely one that deserves a place; and I think CDMS does, too.
Further to our “clear box”, I’ve attached a PPT from Infoway circa 2005 or so – about the time that the blueprint was being socialized within the technical communities in Canada. I’d recommend a look at the whole deck (it’s not a long read, really), but especially around slide 65 there is a bit of a breakdown into the “clear box” of the working elements of the architecture. Things have evolved since this
deck was made so this isn’t actually a definitive example of the present Infoway design… but it provides, I think, a very useful insight into the thought processes that went into the SOA design.
Warmest regards,
Derek.
PS: this and
other stuff is all freely available on the Infoway site. There is also the full set of ALL of Infoway’s design docs that was donated to the HEAL when it was set up in 2010… although I’m sure those pig-o-bytes of data are all archived somewhere by now.
On Friday, February 21, 2014 2:05:46 AM UTC-5, Ryan Crichton wrote:
Hi guys,
@Hannes, thanks for picking this up. I agree completely we should allow someone to upload a certificate if they already have one. I had this in my mind but didn’t represent it in the workflow. I will change it.
I believe for web applications (which pretty much all the OHIE application are) you would just be able to use apache or similar in front of the web app to allow it to use HTTPS. But, you are right we should explore this further because I’m not quite sure on this.
Agreed, but the HIM will set this up based on the certificates that it generates/receives but you are right once it is setup it just works at the transport layer.
Yes, the intention here is that there are times where we will need to inspect the message contents to be able to determine if a particular application has the authority to send this type of message. A concrete example of this is for the HWR workflows where a provider’s details need to be updated, the uuid of the function in the message much be checked to see what type of function this is so that the authority of an application to invoke that function may be checked. In this case knowledge of the message is required, thus it should be handled by a message specific orchestrator. I agree, having an RBAC actor in our clear box seems like a good approach to make this sort of thing simpler. Are you suggesting that we add an ‘IL RBAC’ actor to this diagram to show this more clearly?
Thanks for the comments guys, they have been very helpful. Keep them coming.
As we discussed, the process at step 1 is something we may want to start collecting information on (in a parking lot). I’m happy to contribute to that.
I believe we should be more precise about step 5. It is at the OS level that certificates are typically installed; few applications are certificate-aware. We do want to adopt a 1-certificate per application posture, but it isn’t clear to me how that will be done without expecting a code change at the app level. We might want to prototype this aspect a bit to see how it could work in practice.
Step 7 is, happily, a transport-layer thing. There should not be anything the IL needs to “do” here. This is our “we don’t talk to strangers” policy, but it will be set well down in the OSI stack. We may want to add a note to that effect.
The ALT block (deep inspection required?) would seem to indicate that this will be a specific per-message test re: authority-checking only. In fact, orchestration will be require for every message, at the very least, to determine which registry/repository the message is routed to. Some of these messages will require deeper inspection than others in order to establish authority. I think it might be more precise to indicate that there will be a RBAC actor inside our IL “clear box” somewhere and this actor, who may need to separately communicate with the HWR, might come into play for some transactions. We may, for some query workflows, also have to respect patient consent directives – so our “clear box” might need to also show that we have a consent directive management service (CDMS), too. These two actors typically work, collaboratively, to establish authority re: PHI access transactions.
Hope this is helpful,
Derek.
On Wednesday, February 19, 2014 7:59:06 AM UTC-5, Ryan Crichton wrote:
Hi all,
I have started to put together some workflows to describe authentication and authorization in the IL. This information is fed from both our discussions at the architecture meeting as well as from our previous call. There are 2 workflows, one for system users and one for human users.
Please could you have a look through these and provide any comments and feedback as to how we can better these, or perhaps, where I may have got our intentions wrong. I’m keen to hear any and all feedback.
