As an ISV, what is considered best practice for implementing application role based security? In other words, only allow users to access certain features in the application based on what roles they belong to.We currently just use a table in our database to store this, but it has been suggested that for maximum HIPAA compliance, this isn't secure enough.My first thought was to just use Active Directory groups, as it would seem that is what they are designed for, however, it just doesn't seem practical to rely on our clients IT departments to create groups and assign users to them for groups that are specific only to our application. This can't be best practice for ISVs...At this point it my research, it seems that possibly the best solution might be to use something like Active Directory Application Mode (ADAM) (Active Directory Lightweight Directory Services) and possibly AzMan (Windows Authorization Manager)?Again, this is for a Windows Forms application, not a Web application or in an in house solution.If it matters, we are also in the process of transitioning our home-baked authentication to instead use active directory for authentication.Also of note is this needs to be secure (HIPAA compliant).All the information I can find on these subjects seems to be for developing applications for in house use, or for web applications, and neither of these approaches feels appropriate for a Windows Forms application.(We are using .NET for development.)
How to securely implement roles in a Windows Form application?
security;windows;application design;roles;active directory
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:Unauthenticated usersUnauthorized users - Example: If I have roles(Technician), I should never be able to view data for roles(Physician, Nurse, Admin)Spoofed roles - the user is a Tech but claims he is a DoctorTo be HIPAA compliant the application must:Identify unauthorized accessIdentify which data was accessedIdentify when it was accessedIdentify where it was accessedIdentify who accessed itRecord the eventNotify appropriate parties of the access in a timely fashionSome 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:Stores roles for the organization in a standard format that a Windows system administrator might be more comfortable with.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.