C# – How to store data for Windows Store apps

You probably won't use Windows Forms anymore for Windows 8 development.

Try VS 2012. Check: visual-studio-express-for-windows-phone. Quote from that page:

"Windows Phone SDK provides Visual Studio Express 2012 for Windows Phone and the assets to build epic apps faster using what you know. Use .NET to build your apps or take full advantage of the platform for your games with DirectX/C++. .NET apps and games can reuse their business logic across Windows 8, the web (ASP.NET), and Windows Azure so developers can move faster."

A Microsoft (free) book that may help you know more about Windows 8 development is at: Programming MS Windows 8 Apps with HTML, CSS and JavaScript. I am not sure about the free part it may have restrictions or the offer may have expired.

Moving the roles to LDAP / AD as a solution isn't going to address your root problem in a simple fat client architecture, but that isn't a reason not to do it, read on...

In the case of HIPAA security, we want to implement a system such that someone that knows database security and .NET internals can't hack your system by reverse engineering your application. If I were to audit your application, a disassembler and a network sniffer are two of the tools I'd use.

Don't get distracted with "we don't know who has the database password..." and all that. HIPAA doesn't depend on that. That isn't the application's concern. Actually in a HIPAA-secure environment, you will assume that certain people are authorized to maintain the system data, and it isn't up to you to solve all potential security problems in the organization. Likely the owner/doctor and system administrators will have access to all of it. Much of HIPAA is legal contract. A HIPAA security implementation requires you to place some level of burden on the customer to maintain the appropriate policies and procedures at their healthcare practice.

The customer, and their staff, will have all signed HIPAA contracts that pertain to their role in the customer organization. So will you, if you are engaged to install, maintain or support the system in any capacity that means you may touch data. All other partners, associates, including system administrators and third-party contractor, will usually be covered by BAA agreements, based on who they are and what data they may handle.

For an RBAC architecture, our job is to secure the application. As an PHI Application Architect, we are concerned, in our application, with security of PHI data from:

1. Unauthenticated users
2. Unauthorized users - Example: If I have roles(Technician), I should never be able to view data for roles(Physician, Nurse, Admin)
3. Spoofed roles - the user is a Tech but claims he is a Doctor

To be HIPAA compliant the application must:

1. Identify unauthorized access
2. Identify which data was accessed
3. Identify when it was accessed
4. Identify where it was accessed
5. Identify who accessed it
6. Record the event
7. Notify appropriate parties of the access in a timely fashion

Some companies use very broad definitions for a HIPAA compliant application, but in designing several EMR systems and having had to answer a lot of hard questions from customers, CEOs, auditors, and critics, I've learned that if I use sound computer science, I can formally prove that the system is secure (bugs notwithstanding).

So in that light, what does LDAP accomplish? There are a couple of benefits that have nothing to do with security:

1. Stores roles for the organization in a standard format that a Windows system administrator might be more comfortable with.
2. Centralizes roles such that other applications can share these roles, and you don't have to repeat yourself.

So it's a good thing. Large organizations have a lot of separate systems and a lot of duplicate data and entry. Particularly hospitals! If you can support LDAP and HL7, you can possibly plug in to their IT infrastructure (but usually with a bit of customization). To be competitive, it is a good feature.

But LDAP alone solves nothing regarding enforcement of roles and data access; you shouldn't make it a requirement to run your application (unless you are in the mid- to high-end space where the cost and skill set requirement is minor compared to the overall price of the application, or your application is for a specific organization that already has AD). For small "mom and pop" practices, your application should be turnkey, probably on a simple architecture of one or two PCs or a PC and a cheap server. We often think of healthcare practices as cash rich, but as I'm sure you know, the truth is many of them are not, or if they were, they have already been burned over and over by software vendors claiming to have the total solution. That said, I'll proceed now on pure technical aspects and leave your business to you.

Technical Perspective:

A good practice is to think as if your front end application is written in Ruby (or some other scripting language). I can compromise a compiled binary if I have read-access to that binary program. On most OSes, if I can run it, I can read it. The privileges are Read Write and Execute (X), and X doesn't come without (R). So assume with a .NET local application, that I can decompile the application.

Don't entrust authorization and role management to the client application. I should not be able to use knowledge of the code to obtain data from the database that I have no rights for. If I decompile the end user application, replace the string "TECH" with "ADMIN", it should only impact the application, not the data access. However, it is perfectly acceptable to use these roles in the application for controlling which screens are presented. Screen access doesn't dictate data access. Don't burn up man-hours trying to control screen visibility. Assume a well-behaved user. If he tries hard enough, he gets a blank screen, but it isn't usually worth writing code for, just worry about the data.

If the application is designed to use individual database users (i.e. I authenticate to Oracle as MSMITH, and MSMITH has its own views to protect the base table data) then you can still get away with direct database access, as long as the roles are protected, and enforced. However, many (most) designs use shared-schema multitenancy and application/LDAP managed users and roles, and in that case, to really solve the problem, you have to introduce a middle layer; a gatekeeper that doesn't trust the application. The gatekeeper will independently authenticate and authorize the user's role and only serve up data accordingly.

Storing the roles in a database isn't less secure. We just can't allow people to assign roles to themselves (unless that is their role). And we can't allow the RBAC to be circumvented.

That leaves you with a decision regarding your architecture. Whether to move the database and/or gatekeeper of the data into a realm that isn't accessible to the user or front-end application, except through some communication protocol. This is one reason that SaaS is more secure for EMR applications, it provides a clean solution; the user can't read or directly execute the application, because he doesn't own it or the domain it runs in; he just accesses it through the exposed interface. Many people think SaaS means "cloud", or that they login to some remote application across the Internet. But it simply means your user accesses the software as a service, and the software is centrally hosted. If you think about it, you can architect your Windows Forms application to use the benefits of the SaaS model, or narrow it down to DaaS (data as a service). Move your database off of the client, so it isn't co-resident, or if you must make it work on a single computer, put it in a separate user account or secure VM, and run the application without administration privileges, to communicate with the database through a service layer. The DaaS server might run in a back computer room, or at a remote office; that part isn't relevant.

This solves the security problem completely in that the server can perform the authentication, authorization, and administration of the roles, and no amount of spoofing roles in the client is going to override the server. If your client application has to request data through a service layer, then the security is out of his control, and secure. It may sound expensive to implement; it isn't too bad if you already have an MVC / MVP and/or SOA architecture. And if rearchitecting your application is unreasonable or cost-prohibitive, there are ways to do it purely at the database level with most robust relational databases.