Code for APPLICATION PROXY "authentication" via RPC

[Joel M]

Has anyone developed an external application that uses VistA app proxy accounts? If so, would you mind sharing the code or describing how you accomplished this feat? I've spent the better part of the day digging through M routines, googling, looking at VistaLink source code, etc. and I'm not getting anywhere. Since app proxy accounts don't have A/V codes, it doesn't seem to be as simple as calling XUS AV CODE. I looked through some of the routines behind XUS SIGNON SETUP to see if there was a possible entry point there but didn't see anything obvious.

Thanks!

[Steven McPhelan]

You need to read the documentation that was released with this functionality.  Unfortunately, like the rest of VistA it was released as a patch.  There one would need to find ALL the patches that were released in order to get a complete picture.  Perhaps the KERNEL documentation at http://www.va.gov/vdl has been updated to include this new functionality so that one would not have to find all the patches.

I do know that in the VA this feature is tightly controlled in that any VA application wishing to use it must get approval from mother (i.e., the appropriate VA entity).  The general concept is a type of two factor authentication.  Security is controlled in one aspect in that originator must provide a KIDS build for the customer side that will set up the appropriate files so that the GUI will work.  The customer controls which KIDS Builds are installed on the customer system.  So presumably the customer's system could not be compromised since the customer willingly installed the Build.  The development of this feature in the VA had other assumptions.  Since the VA implemented processes and procedures OUTSIDE of the source code to implement the first level of security there was no needed to have the source code replicate that security.  Remember, in the VA VistA is generally not open to the WorldWideWeb.   That is an example of a first-level security feature that is controlled by processes and procedures.

You should be familiar with two-factor authentication concepts.  It would be helpful if you have had experience in some kind of security models.  You need to read the documentation.  THEN I believe you will understand what the actual source is doing and why.  This feature was developed exclusively for the use of approved machine to machine sharing of information.  Misuse of this feature outside of the intended purpose can easily lead to HIPAA violations.

Steve

An EHR system is not just a big piece of software and a data repository.  David Bowen, CIO/DHA

On Wed, Mar 25, 2015 at 12:37 PM, Joel M <jo...@bitscopic.com> wrote:

Has anyone developed an external application that uses VistA app proxy accounts? If so, would you mind sharing the code or describing how you accomplished this feat? I've spent the better part of the day digging through M routines, googling, looking at VistaLink source code, etc. and I'm not getting anywhere. Since app proxy accounts don't have A/V codes, it doesn't seem to be as simple as calling XUS AV CODE. I looked through some of the routines behind XUS SIGNON SETUP to see if there was a possible entry point there but didn't see anything obvious.

Thanks!

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joel M]

Hi Steve,

Thanks for your insight. For clarification, my inquiry was not intended to be in the context of VA's procedures but instead how one accomplishes app proxy "authentication" at the technical level. I do appreciate your comments - just re-framing the discussion.

I did review a number of the kernel docs on the VDL. Also, KAAJEE's and VistaLink's. I have quite a bit of background with the RPC broker and Vista's authentication/authorization models. I've just never used app proxy accounts before. Maybe I'm searching for the wrong thing? Would you happen to know which docs, specifically?

Thanks again!

[Kevin Toppenberg]

Joel,

Eddie and I waded through this when working with VistALink.  It was confusing.  Try looking in this document:

http://www.va.gov/vdl/documents/infrastructure/vistalink/vistalink_1_6_dg.doc

Esp section 4.1

I seem to recall that there were 3 security models:

-- End user logs in with their own credentials

-- Proxy user, where the application (e.g. server) pretends to be a normal user and logs in as a user

-- Application proxy, where the RPC calls are specifically linked to the allowed user (I'm very unclear on this point).

Kevin Toppenberg

[Steven McPhelan]

From your background, there are APIs (namespace?) to do some of the setup for you.  I believe the Kernel sign-on security routines have been modified by the VA.  Are experience was just to set up a Proxy User for the purpose of HL7 interfaces so that the system has a PROXY,LAB user for example in file 200.  We have not implemented a full proxy, TCP/IP, RPC like communication.  I do know that all security features of the normal sign-on are enforced.  So the Proxy user has to have a MENU BROKER OPTION with RPCs.  The entire security key structure is also honored so that if something is locked with a security key the proxy user must own that security key.  Obviously menu context is verified for that PROXY,USER.

That was KIDS Build that mentioned.  You will need a KIDS build for the M server side that exports the components that system needs like menu context (OPTION), RPCs, Security Keys, etc.  You cannot export the user profile.  But there is an API that will set up the PROXY,USER for you.  My memory is fuzzy here.  There is an "encrypted" key that is used.  The GUI side has to provide that key.  When you set up the PROXY user and application using the APIs you will need that encrypted key value.  Usually this would be handled as a post-install to the KIDS build.  There are about 3,4,5 files that have to be properly setup and properly linked.  The APIs should handle that for you.

I did not look at this from the eyes of a GUI application.  This same process works for one M VistA system talking to another M VistA system.  The client M system open a TCP/IP socket.  At this point I am getting out of my element due to lack of experience.  I read enough to know what and how this could be used and we had projects that could use it.  But we never got those projects off of the ground before I left.

I know this was very basic but I hope it points you in the right direction.  At this point I would have get the docs out myself and reread them and try to set it up.

Steve

An EHR system is not just a big piece of software and a data repository.  David Bowen, CIO/DHA