Archive
Gimme My Damn Data – And Help Me Understand It!
I recently read a Computerworld article that discussed the reluctance of physicians to share patient data with the patients themselves. The article referenced a survey conducted by Accenture and Harris Interactive that found of the 3,700 physicians asked, only 31% felt that patients should have access to their own healthcare records.
“It found that 82% of U.S. physicians want patients to update their electronic health records with information about themselves, but only 31% believe patients should have full access to that record; 65% believe patients should have only limited access. Four percent said patients should have no access at all.”
This can best be represented by the following graphic from the Computerworld article:
This is old school thinking and is akin to asking someone to “show me yours and I will ‘think’ about showing you mine” (but probably won’t). How very one-sided.
When I first joined the Personal Data Ecosystem Consortium (PDEC), I did so because I believed that people should be allowed to take control of their own data. To me, “personal data” was roughly defined as identity and PII data; this was largely due to my identity background. But over the past year this has shifted towards healthcare data and while many of the same thoughts apply, the ROI on managing healthcare data can be much higher as it directly correlates to a person’s primary asset – their health.
Google Health, Microsoft HealthVault, CareZone – there is no shortage of applications designed to assist people in managing their healthcare data. While some efforts have failed, others remain hopeful. But as this survey demonstrates, there is still a long way to go to change the minds of those who are diagnosing and managing this data – the physicians, themselves. If they could only understand that patients are uniquely capable of assisting in the management of their own healthcare; but in order to do so, they need the data (and they need to understand what it means).
Over the past couple of years we have been developing applications that utilize the Lifedash platform. This allows our users to take control of their own data and selectively share it with others. Our latest application is CareSync and it is directly focused on healthcare. We are currently in a beta of the Web application and are piloting our Health Assistant services. Both of these offerings allow people to aggregate and manage their own healthcare in a collaborative environment but allows them to do it safely and securely. The feedback we have received from our participants has been overwhelmingly positive as people are losing faith in the healthcare system. They either want to (or feel forced to) take an active role in managing their own (or family’s) healthcare but to do so, they need the data.
With the reluctance of most physicians to share it is challenging at best. There are, however, techniques that you can use to obtain this information but it requires persistence (the word “nagging” comes to mind). It should not be that way – after all, it is our data.
In the words of healthcare activist e-Patient Dave, just “give me my damn data!” Or as I would add, just “give me my damn data, help me to understand what you just gave me, and tell me how I compare to others in my situation!”
The Real Role of a Leader
A humorous look at the role of a leader in any organization. If you have ever been a leader, I’m sure you can relate to this quote from an anonymous author.
As nearly everyone knows, a leader has practically nothing to do except to decide what is to be done; tell somebody to do it; listen to reasons why it should not be done or why it should be done in a different way; follow up to see if the thing has been done; discover that it has not; inquire why; listen to excuses from the person who should have done it; follow up again to see if the thing has been done, only to discover that it has been done incorrectly; point out how it should have been done; conclude that as long as it has been done, it may as well be left where it is; wonder if it is not time to get rid of a person who cannot do a thing right; reflect that the person probably has a spouse and a large family, and any successor would be just as bad and maybe worse; consider how much simpler and better matters would be now if he had done it himself in the first place; reflect sadly that he could have done it right in twenty minutes, and, as things turned out, he has had to spend two days to find out why it has taken three weeks for somebody else to do it wrong.
Overcoming Personal Battles
Did you know that Lord Nelson, England’s famous naval hero, suffered from seasickness his entire life.
It’s true.
In a letter recently found in the Camden family archives, Nelson expresses sympathy for the 2nd Earl of Camden‘s 16-year-old nephew by admitting to his own personal weakness.
“I am ill every time it blows hard and nothing but my enthusiastic love for the profession keeps me one hour at sea.”
(See YouTube video: Lord Nelson Seasickness Letter in Tunbridge Wells.)
How could the man who destroyed Napoleon’s fleet lead men into battle when he himself was fighting a battle within himself? He did so by not only learning to live with his weakness – he learned to conquer it. And in so doing, he went on to become England’s greatest Naval hero.
Most of us have situations in our own lives that challenge us on a day to day basis. These may be physical or they may be psychological, but rest assured, everyone who has ever tried to accomplish anything in life has had to overcome their own personal seasickness.
Oftentimes it is a private war; carried on quietly within our own lives. But unlike heroes like Nelson, no one will celebrate our victories, no one will recognize our successes, and no one will pin a medal to our chest for winning. But even without the fanfare from others, nothing can dim the quiet satisfaction of knowing in our own hearts that we did not give up!
Cherish the People
I recently spent some time going through old business cards. Netscape, Sun Microsystems, Trusted Information Systems… Companies that were once giants in their industries – now gone. Their technologies no longer discussed except in circles of old folks (like me) reminiscing years gone by. The act of discarding these cards felt somehow like I was closing the final chapter of their very existence.
In a world where LinkedIn has become the electronic business card used by most people, I still felt compelled to hang on to these artifacts. Not for the contact information (that was long out of date), but for the memories that each card had left behind. Each person that I did business with or simply met at a conference has influenced me in some way. Whether it was a simple nugget of information provided by an acquaintance or an introductory meeting with someone that I have built a relationship with throughout the years, those cards represent people that have made me who I am today. For some odd reason I felt like I was throwing away a piece of them and wondered how LinkedIn could possibly replace the paper I held in my hand. Even so, it was time to move on and I continued with my quest.
Before committing each card to the trash, I took a moment to reflect back on those relationships. Some of the names were no longer familiar to me. Notes quickly scribbled on the backs of cards no longer made sense. I was reminded of people I had forgotten and wondered where they were today (I had better look them up on LinkedIn). But as I tossed the last card into the trash, one thing became abundantly clear. Companies and technologies come and go, but people stay a part of you forever.
Discard the cards, but hang on to (and cherish) the people.
What do OpenDJ and McDonald’s Have in Common?
The OpenDJ directory server is highly scalable and can process all sorts of requests from different types of clients over various protocols. The following diagram provides an overview of how OpenDJ processes these requests. (See The OpenDJ Architecture for a more detailed description of each component.)
Note: The following information has been taken from ForgeRock’s OpenDJ Administration, Maintenance and Tuning Class and has been used with the permission of ForgeRock.
Client requests are accepted and processed by an appropriate Connection Handler. The Connection Handler decodes the request according to the protocol (LDAP, JMX, SNMP, etc.) and either responds immediately or converts it into an LDAP Operation Object that is added to the Work Queue.
Analogy: I like to use the analogy of the drive-through window at a fast food restaurant when describing this process. You are the client making a request of the establishment. The Connection Handler is the person who takes your order; they take your request and enter it into their ordering system (the Work Queue). They do not prepare your food; their jobs are simply to take the order as quickly and efficiently as possible.
Worker Threads monitor and detect items on the Work Queue and respond by processing them in a first in, first out fashion. Requests may be routed or filtered based on the server configuration and then possibly transformed before the appropriate backend is selected.
Analogy: Continuing with the fast food analogy, the Worker Threads are similar to the people who prepare your food. They monitor the order system (Work Queue) for any new orders and process them in a first in, first out fashion.
Note: OpenDJ routing is currently limited to the server’s determination of the appropriate backend. In future versions, this may take on more of a proxy or virtual directory type of implementation.
The result is returned to the client by the Worker Threads using the callback method specified by the Connection Handler.
Analogy: Once your order is completed, the food (or the results of your request) is given to you by one of the Worker Threads who has been tasked with that responsibility. This is the only place where the analogy somewhat breaks down. In older fast food restaurants (ones with only one window) this may sometimes be the person who took your order in the first place. In our analogy, however, the Connection Handler never responds to your request. This model is more closely attuned to more recent fast food establishments where they have two windows and there is a clear delineation of duties between the order taker (Connection Handler) and the one who provides you with your food (the Worker Thread).
Other services such as access control processing (ACIs), Logging, and Monitoring provide different access points within the request processing flow and are used to control, audit, and monitor how the requests are processed.
So, what do OpenDJ and McDonald’s have in common? They are both highly efficient entities that have been streamlined to process requests in the most efficient manner possible.
Check out ForgeRock’s website for more information on OpenDJ or click here if you are interested in attending one of ForgeRock’s upcoming training classes.
The Dimishing Non-Digital World (or How to get Outed by a Photo Booth)
I recently attended a high school reunion where a major draw involved the use of a photo booth. You remember photo booths, right? Kiosks where one or more people hide behind a curtain and take pictures of themselves in all sorts of poses. At the end of the session, the kiosk spits out copies of the pictures much to the chagrin of those who aren’t quite as photogenic as they initially thought they were. In our case, reunion attendees were treated to an assortment of funny hats, glasses, and mustaches before entering the booth. They posed with silly expressions, engaged in silly activities, and in some cases even took silly actions to the extreme (I will leave that to your own imagination).
The point I am trying to make is that once the curtain was closed and the camera light came on people began performing in ways that would be considered unheard of in other settings. Adults who mere minutes before were prim and proper were now raving exhibitionists behind the privacy of a thin veil of cloth. When the curtain was once again opened, they returned to their “normal” behavior and giggled as they left the booth with memories in hand.
So why the sudden change? How did a thin piece of cloth make any difference as to how they acted? The difference was not the curtain, the difference stemmed from their perception of privacy and the context of the situation. People tend to act differently in settings where they feel their actions are private and when the context of the situation is known, they oftentimes let their guard down and act more naturally (or more boldly as the case may be). Just think about Congressman Weiner and his Twitter outing, Alec Baldwin and his fatherly advice to his daughter, or even conversations that you may have had over email, chat, or text when you didn’t think anyone was looking. When people feel more secure in their settings (privacy) and know the rules by which to play (context), they oftentimes act in totally different ways.
The problem with this behavior in a digital society is that you are never truely off the grid and it is all too easy for things to be taken out of context when information is shared inadvertantly. In our current digital society privacy is a facade as few companies take privacy seriously and there are fewer online places where your information is truly secure. Unfortunately, that can also be said of our offline world as more and more of it is becomming digitized as well.
Even within the sacred confines of a photo booth our privacy is not really private at all. Ironically photo booths now take digital photos which are then stored on the kiosk’s computer hard drive. While this expidites the printing process, the possability of those photos being shared with unintended parties is very real. At least that is what I observed shortly after the reunion when pictures from the photo booth began appearing on Facebook. At first I thought that attendees were scanning their own photos and posting them. This thought was immediately dismissed when I saw my own pictures start to appear.
From what I can surmise, the operator of the photo booth provided digital copies of everyone’s photos to one of the reunion committee members who took it upon themselves to post the pictures to Facebook. I am not going to get into the legal, moral, or ethical issues behind this action, but suffice to say, no notice was posted and no permission was granted. Now, I truly believe that those involved had the best intentions of the reunion attendees in mind, but the problem is that they did not have the right to make that decision on their own.
Intersection cameras, movies on demand (on any device), automobiles that act as WIFI hot spots, Internet connected scales, and yes photo booths – these are only a few examples of how every aspect of our life is becoming affected (or even consumed) by digitalization. All of that content is finding its way into the hands of people who may have good intentions, but who do not understand the ramifications that disclosure of such information may have. As such, they may not take the same care that you or I might take with our own information and may share it with others – all under the guise of good intentions.
So what happens to our privacy when our information falls into the hands of others? Is it even possible to assume that they have our best intentions in mind when their own companies make money by selling our data to the highest bidder? Can we assume that the context in which we operated is even valid when it may simply be a ruse to get us to let our guards down? Like Rip Van Winkle awaking from his 20 year slumber only to find a world that he no longer recognizes, we too must take care that we resist our own apethetical slumber or we too will wake up to a world we no longer recognize.
The OpenDJ Architecture
An understanding of the components that make up the OpenDJ Architecture is useful for administering, configuring, or troubleshooting the OpenDJ server.
The following information has been taken from ForgeRock’s OpenDJ Administration, Maintenance and Tuning Class and has been used with the permission of ForgeRock.
The OpenDJ server has been developed using a modular architecture in which most or all components are written to a well-defined specification. This image above provides an overview of these components. The following sections provide a brief description of some of the more prevalent components shown in this image.
Configuration Handler
The OpenDJ Configuration Handler is responsible for managing configuration information within OpenDJ’s configuration files (i.e. config.ldif). Configuration information may impact one or more components; as such, the Configuration Handler is responsible for notifying appropriate components when a configuration change occurs.
Connection Handlers
Connection and request handlers manage all interaction with LDAP clients. This includes accepting new connections and reading and responding to client. Connection handlers are responsible for any special processing that might be required for this communication, including managing encryption or performing protocol translation. It is possible to have multiple concurrent implementations active at any given time and as such, OpenDJ includes connection handlers which support various forms of communication that clients use to interact with the server (JMX, LDAP, LDAPS, LDIF, SNMP). Administrators have the ability to enable or disable these connection handlers to support their client environment.
Note: ForgeRock is currently working on REST and JSON interfaces to provide direct access to directory server data.
Backend Databases
Connection handlers place client requests onto OpenDJ’s Work Queue. Worker threads detect requests placed on the work queue and are responsible for performing the processing necessary to respond to the request. Today’s directory servers must be able to handle a tremendous number of requests in a short period of time; as such, OpenDJ’s Work Queue has been built to be both highly efficient and provide high performance.
A backend database serves as a repository for searching, retrieving, and storing directory data. OpenDJ supports multiple backends including those considered typical databases (such as Oracle, MySql, and Berekely DB) as well as file-based and memory-based backends. There can be multiple backend databases active at any given time, each of which handle mutually exclusive subsets of data (selection of the appropriate database is based on the root suffix specified in the operation). OpenDJ facilitates interaction with these backends and provides tools for enabling, disabling, creating, removing, backing up, and restoring the databases independently from each other without impacting other backends.
Note: Backends may consist of local or remote repositories (i.e. the database is stored on a remote machine). This can be found in cases where the backend interacts with a proxy or a virtual server. Support for proxy and virtual server backends are scheduled for a future release.
Loggers
OpenDJ has a robust logging capability that allows server information to be retained in various repositories. The most common loggers are as follows:
- Access Logger – stores server operations (binds, searches, modifications, etc.)
- Error Logger – stores warnings, errors, and significant events that occur with the server
- Debug Logger – records debug information when the server is run with debugging enabled and Java assertions are active.
Multiple loggers can be configured for each of these and each logger may be actively storing different information (filtered or not) in different formats in different repositories.
Note: Some error loggers can be used as an alerting mechanism to actively notify administrators of potential problems.
SASL Handlers
The LDAP protocol supports two methods that clients may use to authenticate to the server:
- LDAP simple authentication
- Simple Authentication and Security Layer (SASL)
SASL is an authentication framework that supports multiple authentication mechanisms including ANONYMOUS, CRAM-MD5, DIGEST-MD5, EXTERNAL, GSSAPI, and PLAIN.
OpenDJ includes a set of handlers that implement each of these SASL mechanisms in order to determine the identity of the client.
Access Control
OpenDJ contains an access control module that is used to determine if a client is permitted to perform a particular request or not.
Password Storage
OpenDJ includes several password storage modules that can be used to obscure user passwords using a reversible or one-way algorithm. Password storage schemes encode new passwords provided by users so that they are stored in an encoded manner. This makes it difficult or impossible for someone to determine the clear-text passwords from the encoded values. They can also be used to determine whether a clear-text password provided by a client matches the encoded value stored in the server.
Password Complexity
OpenDJ includes a series of modules that define logic used to determine whether a user’s password meets minimum requirements or not.
Syntax and Matching Rules
Attributes must follow a particular syntax and search filters determine matches based on a set of matching rules. OpenDJ contains a set of syntaxes and matching rules that define the logic for dealing with different kinds of attributes.
Database Cache
Interacting with data in memory is much faster than interacting with data on disk. As such, OpenDJ includes a database caching module that loads directory data into memory.
Check out ForgeRock’s website for more information on OpenDJ or click here if you are interested in attending one of ForgeRock’s upcoming training classes.
A New Generation of Indentured Servitude
Your digital identity is comprised of information that you volunteer about yourself and information that is observed about you as you simply participate in life. You can (somewhat) control the personal data that you share with others, but have you ever wondered about the type of information that is gathered about you, how long it is retained, and how it is used?
A friend of mine introduced me to a video that provides insight into these questions. It contains an interesting perspective on how your digital identity is comprised, collected and used.
It is interesting to note that almost four years of our lives is owned by someone else – and we willingly give it away. Does that make us indentured servants to those vendors who provide us “free services” in return?
The speaker makes another interesting comment at the end of the video,
The global Internet becomes the personal Internet and information ceases to be information at all.
I am not entirely sure that I agree with that statement; I guess it depends on who it is being made about. Unless we (the ones who generate the data) benefit in the form of better applications, streamlined experiences, or potentially even financial returns, then I don’t see it becoming a “personal Internet” at all.
In our current form of indentured servitude, we continue to give away pieces of our freedom in return for very little.
It is time to turn the model around.
Unlocking the Mystery behind the OpenDJ User Database
One question that arises time and time again pertains to the manner in which OpenDJ stores it entry data and how this differs from the Oracle Directory Server Enterprise Edition (previously known as Sun Directory Server Enterprise Edition).
The following information is from ForgeRock’s OpenDJ Administration, Maintenance and Tuning Class and has been used with the permission of ForgeRock.
OpenDJ includes the Berkeley DB Java Edition database as the backend repository for user data. The Java version is quite different from the Berkeley C version which is used by the Sun Directory Server Enterprise Edition.
The Berkeley DB Java Edition is a Java implementation of a raw database using the B-Tree technology. A Berkeley DB JE environment can be composed of multiple databases, each of which is stored in a single folder on the file system. Rather than having separate files for records and transaction logs, Berkeley DB JE uses a rolling log file to store everything; this includes the B-Tree structure, the user provided records and the indexes. Write operations append entries as the last items in the log file. When a certain size is reached (10MB by default), a new log file is created. This results in consistent write performance regardless of the database size.
Note: Initial log files are located beneath the db/userRoot folder in the installation directory. The initial log file is 00000000.jdb. When that file reaches a size of 10MB, a new file is created as 00000001.jdb.
Over time records are deleted or modified in the log. OpenDJ performs periodic cleanup of log files and rewrites them to new log files. This task is performed without action by a system administrator and ensures consistency of the data contained in the log files.
You can see a list of all entries contained in the database with the dbtest utility. This command returns the entry specific information that can also be used to debug the backend.
The following diagram demonstrates the periodic processing of the Berkeley DB Java Edition database over time.
Log (Entry) Processing
The log shown at the far left (row 1, column 1) contains entries after an immediate population. You will note that it contains five data entries (Entry 1 through Entry 5) as well as the associated index entries. To keep things simple, only the common name and object class attributes have been indexed (as shown by the cn and OC keys).
Note: The data does not appear in this actual format. This notation is used for demonstration purposes.
As time goes by, data in the database changes. New entries are added, attribute values for existing entries are modified, and some entries are deleted. This has an effect on both the data entries in the log as well as any associated index entries.
The second log (row 1, column 2) demonstrates the effect on the database after Entry 3 has been modified. The modified data entry is written to the end of the log and the original entry is marked for deletion. The modification was made to an attribute that that was not indexed so the log does not contain any modification to the index entries.
Changes made to data entries containing indexed attributes would not only appear at the end of the log, but the modifications to the indexes would appear there as well. This can be seen in the third log (row 1, column 3). Entry 2 was modified and the change involved a modification to the common name (cn) attribute. Note how the previous index value for this entry is marked for deletion and the new index entry is written to the end of the log.
The logs found at row 1, column 4 and row 2, column 4 demonstrate how new log files are created as previous ones reach their limit. Write operations are appended to the log file in a linear fashion until it reaches a maximum size of 10 MB at which time a new log is created. This can be seen by the 00000001.jdb log in row 2, column 4.
Note: The maximum log size of 10 MB is defined in the ds-cfg-db-log-file-max attribute contained in the backend definition.
Database Cleanup
The Berkeley C Database simply purged data from the database. This led to fragmentation (“holes”) in the database and required periodic cleanup by system administrators to eliminate the holes (similar to defragmenting your hard drive). This is not the case with the Berkeley DB Java Edition.
The Berkeley DB Java Edition has a number of threads that periodically check the occupancy of each log. If it detects that the size associated with active entries falls below a certain threshold (50% of its maximum size, or 5MB by default), it rewrites the active records to the end of the latest log file and deletes the old log altogether. This can be seen in the log found at row 2, column 5.
Note: Maximum occupancy is defined in the ds-cfg-db-cleaner-min-utilization attribute contained in the backend definition.
The default occupancy is 50% so at its maximum size, the log will be twice as big as its sum of records. Increasing the occupancy % will reduce the log’s size, but induce more copying, thus increasing CPU utilization.
This process of always appending data to the end of the log and periodically rewriting the log as entries are obsoleted allows OpenDJ to maintain a fairly consistent size – even if entries are heavily modified. It does, however, allow the database to shrink in size if many entries are deleted.
Check out ForgeRock’s website for more information on OpenDJ or click here if you are interested in attending one of ForgeRock’s upcoming training classes.
Don’t Just Complain, Do Something About It!
A hopelessly lost salesman came upon a farm house where the owner was rocking away on his porch. Late and desperate to get back on the road he stopped to ask for directions.
“Take the dirt road in the direction that the sun sets; keep going until you go past the old post office. Make a left after you drive past the broken down tractor that them Taylor boys left a sittin’ there,” explained the farmer. “Keep a goin’ a bit more until you pass the old sawmill, …” he continued but was interrupted by his old hound dog who let out a rather painful groan.
“Aroooogh,” moaned the dog.
The farmer continued, “…once you get past old McGreevy’s farm, make another left, and …”
“Arooooooogh”… once again, the dog lets out a painful moan.
“Excuse me,” asked the salesman, “but is there something wrong with your dog?”
The farmer looked down at the dog, paused a second, and then replied, “Naw, he’s just lying thar on a nail”. “Wait a minute,” asked the puzzled salesperson, “if he is lying on a nail, why doesn’t he just get up?” Without missing a beat, the farmer said matter of factly, “Don’t hurt enough to get up, just to complain about it…”
Moral: How many times have you criticized someone for how they are doing something? How many problems have you solved with your friends over beers at the local pub? How often do you feel like you have a better idea? Well, stop complaining about it and do something about it!
Remember: “It is better to light a candle than to curse the darkness.”
 |  |  |  |  |
Easy Identity 