Tag Archives: Identity Management

Will that be Paper or Panic?

According to the New  York Times, 8/10 doctors still use paper record keeping.  As I stated in an earlier blog, the stimulus package will spend a “ga-jillion” dollars on converting paper records to electronic medical records. cited in an article in 2007 that “a key tenet of HIPAA’s data privacy and security requirements is a need for data access accountability, i.e. the ability to understand ‘who is doing what to which data and by what means?’ “ 
In my previous post I talked about how one could secure personally identifiable information by placing the data behind the Netscaler Application Firewall to block or “X” out Social Security Numbers and Phone Numbers.  In this post I will discuss a new feature in the Netscaler 9 product called AAA Traffic Management. This new feature will allow you to impose Authentication, Accountability and Authorization on downstream data that may be on servers that do not live within your AD Domain infrastructure. Regardless of what platform the content lives on and which identity management system they are using, you can force users to authenticate and have their access logged meeting several regulatory rules and ensuring the ability to see “who’s doing what to which data”.

 Deployment Scenarios:

 Scenario 1:
The incumbent identity management solution for Company A, a publicly held company on the NYSE, is Active Directory.  They recently acquired another company who was not public and not subject to the regulatory framework that Company A is and lacks any security measures on key data that now must be secured.  To make matters worse, much of their data resides on an OS390 that has a 3rd party web server.


  • You can quickly make this data available by creating a service on the Netscaler that maps to the OS390 web server. 
  • When you create the VIP to present the data, enable authentication and bind a AAA Traffic Management VIP.
  • Create an LDAP Authentication policy that leverages your existing AD Domain Controllers. 

Now when users connect to the VIP on the Netscaler they are redirected to the Authentication VIP and forced to log in with the domain credentials.  This will help limit the number of logins that they have as well as the amount of RACF administration that needs to be done.  Also, the Netscaler will syslog all access to this data. 

Scenario 2:

You ARE a local doctor who is moving to electronic data by scanning files into a database and making them available via a PDF archive.  You are bound by HIPAA to account for every single person who looks at that data.  You place the PDF’s on a web server, index them and allow end users to access them but cannot report on who accessed what PDF archives.


  • Again, we deliver the web server via a VIP on the Netscaler and enable authentication
  • Ensure that everyone who accesses the data has to provide one or two-factor authentication

Now every binary file, including the PDF’s, that are accessed is logged into the syslog database or event correlation engine. 

Scenario 3:

You a web server in the DMZ that has a few corporate presentations that you want your staff to be able to access but you do not want to be available to the general public.  Since the system is in the DMZ you cannot provide AD Authentication but you want to account for everyone who accesses the presentations and you do not want to use an impersonation account or replicate your existing AD Database with ADAM or DirXML.


  • Yet again, place the presentations behind a Netscaler and create a VIP to present web server housing the presentations.
  • Create an authentication policy using Secure LDAP over TCP 636. 
  • Set up an ACL allowing the NSIP to traverse the firewall to a domain controller (or in my case, a VIP consuming several domain controllers)
  • Bind the authentication policy to an Authentication VIP. 
  • Configure the VIP for the presentations to use the FQDN of the Authentication VIP.

Scenario 4:

You are a CRM vendor like envala or Sales Logix and you have a customer who wants to access their Customer database hosted using SaaS (Cloud Computing).  They would like users to log in against their LDAP server to access the CRM data so that identity management can be handled on their end.  That way if a salesman leaves they can disable their account with out the fear of them logging into their CRM database and stealing leads or the delay in removing that account while the create a support ticket.  Also, since they are consuming this as a SaaS solution, they want you to provide logs of who accessed the system.     


  • Have them make their AD Domain Controller available securely via LDAPs on TCP 636 or they could also use a netscaler to provide a VIP that brokers to the same domain controller.  They can also set up an ACL allowing your NSIP to traverse their firewall for authentication. 
  • Create an authentication policy using Secure LDAP over TCP 636 and point the Server to the customer’s LDAP server. 
  • Set up an Authentication VIP assigning the policy you created for the customer to ensure that it consumes the appropriate LDAP server. 
  • Create a VIP on the Netscaler that front-ends their CRM website.
  • Configure the VIP for the presentations to use the FQDN of the customer’s Authentication VIP.

 Figure A: (Shows external users being redirected to an an external Authentication source via Policy) 



As I stated previously, my experience with HIPAA is limited and much of the accountability has been accommodated by back end database programming, including down to the actual record.  However; as the security screws become tighter and tighter, on a collision course is continued access of data with “IUSR_” or “apache” accounts and the mandate(s) for accountability and the demand to be able to report on who accessed what.  I believe that the AAA Traffic management feature provides a great tool enabling you to impose your identity management solution to any web based content regardless of platform.  Additionally, you get the ability to perform endpoint analysis on incoming clients who can be interrogated for specific registry entries, services and files that can be hidden in a system to ensure that only certain computer systems can access certain files.  Having been part of a paper-to-electronic transition that did not go so well several years ago, I can attest that having tools that can bridge the regulatory gap between legacy systems and today’s heavily gaurded environments will make life a lot easier.

See this technology in action at