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.

It seems to me you want to protect your application from two perspectives:

1. You want to make sure that only authorized people can modify your role-based security via the official user interface for role-based security management.

2. You want to make sure that people can’t view or modify your role-based security via an unofficial mechanism.

This first part is pretty easy, you include a role in your application for maintaining role group members and role authorized actions. Connecting this to (or forcing it into) your customer’s AD is a bit dubious. You don’t know how well the customer manages their AD. Also, what if they use something other than AD? The complexity of connecting to and integrating with your clients’ AD is something that may raise its own HIPAA or security concerns, i.e. some clients may not allow your application to connect to your AD to get information about users.

The second part is a concern for storing your role information in a database. How many people know the DBA password for your clients’ systems? You don’t know, so how can you be sure that you are secure? You want to encrypt the role information in your application’s database and obfuscate the code that accesses it. This will reduce the risk of someone viewing or changing the role rules with plain old database tools, for example. Since you’re dealing with private information, you probably need to consider encrypting all of your sensitive data, not just your role-based security rules.

Let your client’s IT department concern themselves with who can get basic access to your application. This is the bread and butter of IT departments. Once a user gets to your application, however, you need to take responsibility for who is logged in and what they can see and do.

The Solution can be implemented in following method. The required screens in the application would be.

• User Group Master – Create Multiple groups from the screen
• User Master – create multiple users from the screen
• User Group Detials Master – Select User, the screen would list different user group. Assign different groups to the user.
• User Group Rights Master – Select the Group, List different menus in the application and grant different privilages.

Method For Implementation

• Assign Menu ID to all Menus, Keep a menu master table to list in screen for assigning rights.

• Create a rights details table with menu id,group id and different rights you want to control,visibility,save,editing details and additional stuffs based on your requrements.

• Create a function checkpermission while doing any operations in the screen or accessing the menu item with the menu id and the permission to check and user id as parameter. The function will return value True or False and the rights can be controlled.

The same can be achieved in Web Application also. It has been implemented succesfully in various personal projects which I had undertaken.
Additionaly you could also have an Audit log insert in the permission checking function and provide access reports based on screen accessed or data modified on screen or task completed on screen or additional task you would want logged in your application

Alternatively, Coupled with the Same you can generate and ldap Authentication function using active directory services. With this you
will be able to log on to the System only when the user logs in from
the specified domain set by the IT Administrator group.

You can also find a sample code for the same and can develop based on the same.

using System.Text;
using System.Collections;
using System.DirectoryServices;
using System;
using System.DirectoryServices.AccountManagement;
using System.ServiceModel;namespace ClassLibrary
{
    public class LdapAuthentication
    {
        #region Variables/Constructor
        private string _path;
        private string _filterAttribute;

        public LdapAuthentication(string path) 
        {
            //to initialize the Active Directory path
            _path = path;
        }
        #endregion

        #region User Authentication
        public bool IsAuthenticated(string domain, string username, string pwd)
        {
 #region Active Directory Direct Connection
            //accepts a domain name, user name and password as parameters and returns bool to indicate whether or not the user with 
            //a matching password exists within Active Directory. The method initially attempts to bind to Active Directory using the 
            //supplied credentials. If this is successful, the method uses the DirectorySearcher managed class to search for the 
            //specified user object. If located, the _path member is updated to point to the user object and the _filterAttribute member 
            //is updated with the common name attribute of the user object

            string domainAndUsername = domain + @"" + username;
            DirectoryEntry entry = new DirectoryEntry(_path,  domainAndUsername, pwd);
            try
            {               
                // Bind to the native AdsObject to force authentication.
                Object obj = entry.NativeObject;
                DirectorySearcher search = new DirectorySearcher(entry);
                search.Filter = "(SAMAccountName=" + username + ")";             
                search.PropertiesToLoad.Add("CN");
                SearchResult result = search.FindOne();
                if (null == result)
                {
                    return false;
                }
                // Update the new path to the user in the directory
                _path = result.Path;
                _filterAttribute = (String)result.Properties["cn"][0];
            }
            catch (Exception ex)
            {
                throw new Exception("Error authenticating user. " + ex.Message);
            }
            return true;

            #endregion
        }
        #endregion
}
}