Yep, that’s the password my wife and food blogger Foodiesuz received from Food Network Canada last night.  Via plain-text email of course…

Lucky for her, Foodiesuz was not destined to use good ol’ v[ep_!)7@=2n9B forever.  (She’s busy! Who has 3 minutes to type a password anyway?) There was a link to change the password to something more friendly.  But the user selected password had no rules for composition as far as we could tell, i.e. it could be a simple dictionary word.

Perhaps most strangely, the new password takes time to be activated:

User Password Reset
You have requested that a new password be generated and sent to your email address(zzz@yourdomain.ca). Please allow up to 15 minutes for it to take effect.

What is the point you Food Network Canada people?!?  You’ve seriously missed the boat here with your password policy and subsystem:

  • The value of the information being protected is nominal.  You don’t need a strong password, let alone the abomination v[ep_!)7@=2n9B…
  • If you think the account needs such a strong password, why send it in plain text email? And why do you allow dictionary words when the user resets the password?
  • And just what is happening in those 15 minutes anyway? This is very curious… Do you have someone typing a memo to be authorized by management?

Truly odd.


Identity in health services delivery

I came across this interesting headline a while back: Healthcare Identity Management Is Necessary First Step to Electronic Health Record Interchange.  The article has a link to a briefing from the Smart Card Alliance.  While this is an American organization, the context is similar enough to the Canadian identity management issues in health service delivery.  The briefing has a fascinating statistic:

More than 195,000 deaths occur in the United States because of medical error, with 10 out of 17 medical error deaths due to “wrong patient errors.”

The implication is that a large number of lives could be saved by improving identity management, and the brief’s answer to this is, predictiably, to implement smart cards.  The Smart Card Alliance feels that all citizens and health services professionals should be issued cards.

First of all, I think that smart card technology is very well suited to high-value transactions like those carried out in the health sector.  The form factor is convenient, the technology is robust and there are some good solutions out there that make session switching on shared computers fast and easy.

But in health service delivery, particularly in Canada, the identity and access issues are not the real concerns for physicians — whether I am insured or not, whether my health information is online or not, the physician’s job is to diagnose and treat.  This is particularly true in acute care situations such as emergency.  My understanding is that doctors and nurses in those environments are reluctant to use systems if those systems get in the way of treating sick or injured people, even if those systems contain in-depth medical records. Implementations of smart cards — or any other technology — need to be slick and flexible to be adopted.

On the patient side, I agree that it makes sense for patients to access their own electronic health record over the Internet. Smart cards are touted by the Smart Card Alliance as being a secure solution for strong authentication over the web, and although I’m aware of some exploits, it is a proven technology. The issue then becomes how to provision all those millions of users.  There are certainly some good processes out there for identifying individuals, but because most of them require in-person registration (or some other form of corroboration) there is the question of cost.  I know in Alberta we have recently empowered our network of registry agents to perform eligibibility services (i.e. identification) for the health system and presumably this could be used to issue a smart card or other second-factor credential.

How would a fractured American system handle this provisioning?  Who would be responsible for issuance, changes, revokation, ruling on eligibility, etc.?  And who will pay for the smart cards and readers?

And what privacy issues would emerge from such a solution?  Keep in mind that a strong credential such as a health services smart card would have the potential to become a national credential for Americans. Identity fraudsters would seek out weak links in the on-boarding process to obtain this valuable credential. And future governments would have the ability to link medical and other records to a host of other databases…

Clearly, users would need to have clear rights and remedies, something that may be difficult in a country that does not have national privacy legislation.

It is a complicated topic, one that the Smart Card Alliance’s brief does not properly address in its zeal to promote their specific technology.


A Vision for identity management in Canada

The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that
supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric,
multi-channel service delivery experience when interacting with government.

IAM strategy consulting

Most of my consulting work consists of advisory, planning and delivery services in identity management.  So it is no surprise that one of my interests is in seeing how the Pan-Canadian Identity Management & Authentication Strategy can be applied to a variety of IdM projects.  This strategy holds promise for the future development of a national identity framework, one that can cross government jurisdictions and programs.

The Task Force that developed the strategy established a clear vision:

The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience when interacting with government.

For those of us (all of us?) that have had dealings with federal, provincial and municipal governments, this is clearly an ambitious vision. It is fair to say that even working within a single government department today — let alone across jurisdictions — is not seamless and rarely is it multi-channel.  When working between different government departments we encounter a patch-work of online, phone and in-person services that require us to present identification at each step and in inconsistent ways.  Improvements in these areas are clearly in our best interest as citizens and tax payers.

The Pan-Canadian vision promotes standards collaboration.  There must be a basis for establishing ‘trusted, collaborative relationships across jurisdictions’, and only through agreed-to standards can we make this goal a reality. This is particularly true in the high-value online service delivery channel.  Identities for use with applications that require high levels of identity assurance must be well supported by issued organizations to be effective in a cross-jurisdictional use case.

The vision also recognizes the importance of leveraging existing IdM infrastructures — clearly many jurisdictions (and departments within) have IdM services in place that can be adapted and leveraged.  The Pan-Canadian vision does not compel organizations to discard functioning systems, and this shows up in one of the service delivery design principles:

The ability to leverage existing infrastructure and the increased interoperability of systems.

So how does such a vision get realized?  How does a country that is famous for regionalism and inter-jurisdictional disputes move towards a unified and collaborative model?

  • First, governments can improve the chances of realizing this vision by making identity management a priority. In a country as prosperous as ours, the issue is rarely funding but rather one of priority. Establishing that e-government and e-business need IdM to fuel economic and social development in Canada is key to moving forward.
  • Second, the momentum that we are now seeing in implementing the Pan-Canadian strategy needs to be maintained. In-flight projects need to be completed, new ones identified and communications between all parties increased.  Flexibility in the establishment of standards — recognizing differences and allowing for variances — is necessary if all parties are going to participate fully.
  • Finally, the standards that emerge from the project work need to be quickly codified and become mandatory for inter-jurisdictional transactions. I realize that ‘quickly’ is a relative term, but we can’t be talking about standards development five years from now — we need the basic standards and protocols established in the next 12 months if we are going to catch up to what the rest of the world is doing.

A vision of a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience is very much in the ‘go big or go home’ category — and now that governments are starting to become engaged in the execution of the Pan-Canadian strategy, it will be interesting to see how the resulting solutions match up to this ambitious vision.



IAM Defined

What is Identity & Access Management?

  • The Free Dictionary provides this definition: The management of a user’s identity. Within the enterprise, an identity management system comprises a system of directories and access control based on policies. It includes the maintenance of the system (adds, changes, deletes) and generally offers single sign-on so that the user only has to log in once to gain access to multiple resources.”
  • The Internet 2 Middleware Initiative offers that “IAM ensures that the right people access the right services.”

  • Wikipedia doesn’t have an IAM definition, their closest is for Identity Management: “a broad administrative area that deals with identifying individuals in a system (such as a country, a network or an organization) and controlling the access to the resources in that system by placing restrictions on the established identities.”

Identity & Access Management (IAM) allows an organization to do more online with their users and stakeholders.  It provides assurance (to the degree requried) that the online user is whom they claim to be.

Bottom line: IAM enables meaningful e-commerce and e-government by providing much-needed identification and accountability.

Protecting Sessions with Presence Detection

One of the more difficult aspects of implementing Identity & Access Management solutions is properly managing the security of a user session after authentication. Traditional systems rely on things like timeout counters to determine when a user has stopped using their computer.  Once a timeout occurs, the operating system or application will force a logout to occur.

On even the most cursory review, it is easy to see how this approach is flawed. If the timeout is too long, a malicious user could simply wait until the authorized user has left their computer and take over the session. Typical timeouts are 20 minutes which gives an interloper plenty of time to gain access to a neglected session.  Solving this problem by shortening the timeout can cause users to login more frequently, impacting productivity and creating frustration.

The response to this is to train users to logout when they leave their computer unattended.  But, this can be inconvenient and unproductive, particularly in demanding environments where time — even a few seconds — is at a premium.

What if a user’s presence in front of a computer could be detected and, when he/she is no longer present, have the session lock automatically?  This is the premise behind Viion Systems‘ Sentinal Sign-Off solution.

Using standard web cams the system automatically scans and detects a user’s facial features. Once authenticated, the camera will track those unique features and automatically lock the session when the user is no longer present. Upon the user’s return, the Sentinal software will detect the correct facial image and the session is automatically unlocked.

Viion call this ‘Active Presence and Identification’ technology and it is specifically designed for those situations where highly sensitive data is accessed and where a short timeout configuration would introduce unacceptable inconveniences.

It can also be used in organizations that want to prevent users from sharing a session.  For example, two users at a counter service may have one computer to share. In many cases, they will simply leave their session running while a co-worker accesses applications under the first user’s credentials. Obviously, this practice would not be compliant with the security policy at many organizations.  The Sentinal Sign-Off system can eliminate this weakness.

It is worth noting that the system does not need to store the facial image or video data.  It establishes a link between the session and the individual for as long as the session exists, then discards the data. User privacy concerns should not be an issue with most implementations.  (It does have the capability of recording and storing images, but this is not required for the solution to work.  The recording of images feature can be used for specific security cases that clients may have.)

I had a demo of Sentinal Sign-Off system last week, and can confirm it operates as advertised.  One handy feature is that when it ‘loses sight’ of the user, it will show a countdown.  When you return to the field of view, the countdown stops.  The demo showed how a Sentinal login screen is displayed after session locking, but the company assures me that it can pop up a Windows or application login screen if required.

Viion’s system isn’t the only method that can be used to meet this business needs. Sonar, proximity devices and pressure mats all offer similar capabilities — but each has its own limitations.  For example, sonar cannot distiguish between people and inanimate objects.

Aside from some great user convenience, this looks like a solid session management system for niche business needs.  I can see it working well with health services applications, financial systems and certain operations consoles where there is a demand high security while maximizing user convenience.


Health Sector IAM Survey

A US survey of over 260 IT decision-makers by Imprivata has some interesting findings:

87% of respondents are planning to transfer all patient data to an electronic health record (EHR) format within the next two years

62% cited ‘unauthorized access to clinical applications/patient data’ as their number 1 security concern for 2009

54% indicated that they already have user provisioning in place, or plan to implement provisioning

65% felt that it is important or very important to implement clinical context management for synchronized patient context across applications

None of these stats are particularly surprising.  Those responsible for delivery of clinical systems want high security, efficient user management and slick context management within user sessions. Health services delivery demands these capabilities in their IAM systems, and IT will invest in process and technology to meet these needs.

But does the fact that this is a vendor funded survey overly bias the findings?  Is this just another piece of slick marketing under the guise of ‘research’?


Identity Providers in Government

Most of my consulting projects are delivered in the public  sectors: higher education, central services, municipal and, a few years ago, in the health department. Until recently, my projects have involved implementing systems to deliver identity and access management — usually on a deadline, usually for a specific application or set of applications.

But I have also had the opportunity to work on more conceptual projects including defining an IdM strategy for a government department. Starting in the next few weeks, my team will begin architecting and designing federated and user-centric identity solutions.

The first thing we are working through are use cases that will help drive out solution designs.  We already know what the technologies are capable of and we have selected the products we need to conduct the proofs-of-concept.  But what are we going to do with this technology?

If we break down the emerging identity model into Identity Providers, Service Providers and Users, we can define actions in our use cases by these actors.  This post starts the discussion with what makes a good Identity Provider (IdP).  Specifically, the discussion is around the Citizen to Government context.

Who should act as an IdP? I believe that there are actually a limited number of government organizations that can fulfill this role.  While many government departments (and divisions and branches within those departments) might maintain citizen information, only a few actually maintain citizen registries.  And it is these registries — legislated databases of citizen information that are highly secured and carefully maintained — that are ideally suited to supporting an IdP implementation.

Why? Because citizen registries matter.  These databases are consistently used for identification to support both real-world and electronic transactions. A registry of citizens is used to support eligibility for health services in a province. A registry of drivers allows for issuance of drivers licenses and enforcement of road use laws. Student registries ensure that the right student gets credit for exam results, course marks and certifications.  The tax department keeps a reliable registry of citizen tax payers.

In my home province there are also registries for seniors, land titles, vital statistics, children/youth, and a perhaps few others — but that’s about it.  Federally we have citizen registries for taxation, family benefits, veterans, guns (well… the people that own them), and others.

The point to all this is that there are a finite number of authoritative sources of citizen identity information.  It therefore makes sense to leverage these databases for purposes of building reliable identity provider services.

I would even take it a step further — it makes very little sense to build a citizen IdP that is not built on a government registry. Why? Because the legislative authority to build a registry — and the effort to maintain it over time — are not trivial things. Therefore, government departments that contain registries take the job seriously. Registries are secured, monitored and carefully updated.  They often contain key identity attributes such as legal name, date of birth and residential address. Registries are subject to review by provincial and national privacy commissioners. Some registries contain some unique information as well, such as relationships: parent to student, husband to wife, driver to vehicle.

In the event of problems, bodies that manage registries have processes for citizens to correct information to contained in these databases. Most of us care very much if a registry does not have our correct information.  Errors can lead to late payments, loss of hard-earned certifications or denial of critical services.  For example, if the tax department mis-spells our name, it is difficult to cash our refund cheque and we’ll be certain to correct them at the first opportunity.

To further bring this point home, consider the municipal property tax role.  The city maintains this database and it is important to them that the rate payer be linked to correct property.  They want to know who to contact if taxes are in arrears or if a ticket needs to be issued for icy sidewalks.  But municipalities don’t deliver most of the type of life-sustaining or entitlement services that truly matter to us.  Cities and towns also don’t have a business need to record useful identity information like date of birth or gender.  If my city tax assessment arrived and my name was spelled incorrectly, I would probably ask that it be changed, but there would be limited consequences if I didn’t. For these reasons, the city’s tax role would make a poor choice as an IdP.

But a municipal government still needs to deliver services based on citizen entitlements, and identification can play an important role in electronic service delivery.  So if my city’s own databases are poor choices, where should they turn?  To a higher level of government, namely a provincial or federal IdP based on a robust registry.  By establishing an agreement with one or more registry-based IdPs, my city can focus on delivery services — acting as a Service Provider — and leave the more difficult identification and authentication of citizens to an IdP.

Finally, the idea of using registries is aligned with the Pan-Candian Identity Management and Authentication Framework.  While use of registries is not specifically prescribed, the concepts presented in the Identity Component — identity context, identity lifecyle, identity assurance levels and identity relationships — seem to map well when considering registries as ‘sources of truth’ for identity.

There will be a proliference of IdP services established over the next decade so the quality of identity proofing — especially for establishing credentials that are use in higher value transactions — is critical.  Establishing Identity Providers that are based on government registries will be key to the success of future identity management and electronic service delivery initiatives.


User-Centric IdM for the Public Sector

Moving forward, user-centric Identity Management is clearly an interesting alternative to centralized systems.  The promise of a solution where the user has choice over how and what identity information is shared with Service Providers is worth working towards.  It is not surprising that user-centricity is finding its way into pilots and initial implementations in the public sector.

It is becoming clear to me that user-centric IAM is a philosophy / model / strategy that is well-suited to government implementations because it has potential to return ownership of identity information to individuals, many of whom access multiple public services.

If they can avoid it, Canadian governments do not want to hold identity information outside their highly secured core registries.  These government departments recognize that our relatively tough privacy laws prohibit retention of information beyond what is needed to deliver a service.  Storing additional identity information, or unnecessarily storing the same information in more than one place, increases the risk of breaches and identity fraud.

Adopting user-centric strategies can reduce the volume of sensitive data to be managed, move privacy decisions closer to the user and make governments more compliant with their own legislation and policies.  Perhaps most importantly, as Dick Hardt’s Identity 2.0 presentation made it clear, user-centric IdM allows the creation of privacy- and user-driven solutions that mimic the real-world we live in.

This is possible because many systems do not necessarily require identification, but rather authorization.  Or if they do need identity information, they need it to support a transaction and have little need to store it after the transaction is completed.

Think about an e-commerce transaction using a credit card.  The system does not actually need to permanently store identity information. Rather, it needs to know that you have the funds to cover the transaction.  The key information is the card number.  Your name is only provided to support the transaction, i.e. to verify that the card being used can be matched to an accountable card holder.  If these authorization elements are present in the transaction (and not disputed later) then the business can be conducted.  The storing of the name information beyond a reasonable dispute period (say 45 days) is unwarranted.

When faced with breaches of identity information, goverments may soon find themselves needing to identify less.  It may seem counter-intuitive, but for certain low-value business transactions, a government organization may not actually want to know very much about those individuals, or at least they don’t want to have to store information about them in local databases.  What they do want is to ensure that these citizens are authorized to access the system and the information it contains.

An example of a provincial service that could likely dispense with traditional retention of identity information would be a system that issues a fishing license.  When issuing the license, it is important for the individual to properly identify themselves so that their name can be printed on the actual license document.  The license then authorizes the named individual to fish, so after the transaction it is important to have that identity information on the card to support an enforcement officer’s needs for proving ‘eligibility’.  While the issuing department may make a case for retaining the identity information in a license database, does it need to have its own Identity Provider service — chock full of duplicated identity information? Can it not simply trust one of several provincial or federal Identity Providers?

In time, this user-driven approach should result in fewer identity providers and many more relying service providers.  In a provincial government, there could conceiveably be three or four identity providers.  These could be linked to key registries such as HR (for internal users) or public education, health or motor vehicles (for citizens).  Add to this a federally provided IdP, perhaps based on tax records or a passport database, and citizens would have real variety in IdP services.

Moving to user-centric IdM with real choice in identity provider services can provide greater privacy protection and reduce the complexity of government electronic service delivery.


Identity Assurance — Putting it Together

Last in a series [ <- previous ] [ <– first ]

When I reviewed the Pan-Canadian Identity Management & Authentication Strategy in 2008, my first interest was to understand what it could mean to my client’s identity management projects.  In the area of Identity Assurance I was, frankly, hoping that this new framework would not stray too far from the baseline standards and methods I had been using since 2003.

It turns out that the Pan-Canadian Assurance component was fairly close to the approaches I was already using. Where it differs is primarily in terminology or in the way the classifications for information, registration processes, credential strength and overall assurance have been organized.  Another difference is in the ‘stitching together’ of all components that make up Identity Assurance.

To put this to use on your projects, you need to first establish organizational standards that are aligned with the Pan-Canadian Assurance component:

  • Create a set of four information classifications — and provide examples of your own information when you draft this standard.  These map to your requirements for Identity Assurance Levels.
  • Document standards for registration processes that map to the Assurance Levels.  These don’t have to be detailed use cases, but rather descriptions of minimum process sets that are needed at each level.
  • Select different levels for credential strength by combining passwords, ‘secrets’, issued authenticators, and — if it is applicable to your business applications — biometrics.  Keep in mind that the quality of the operational infrastructure needs to be consistent with the authentication events you plan to support.

Once these standards are in place your system design can be formally supported.  The process that each project will need to follow is summarized as follows:

  1. Classify the information that will be accessed — this becomes the Security Classification of Information.
  2. State the Identity Assurance Level required (it is the same as the Security Classification).
  3. Determine which Registration Process will be required to match the Level of Assurance.
  4. Select a Credential Strength at the same level.  This is a critical decision — it needs to be strong enough while still being affordable and sufficiently convenient to use.
  5. Review the design: analyze the levels assigned in each category and document.

One final comment: the Pan-Canadian Strategy defines a framework, not a set of fixed rules.  Adapt the models and components described in the strategy to suit your business needs.  Provided you don’t stray too far from the intent of the framework, your systems will still be able to interoperate with others that based on the framework.


Tired of reading? Check out the 72 Things I’ve Learned About IAM

For more information on designing identity assurance systems and processes, please contact Code Technology at info@codetechnology.ca or 780.990.7742.

PS2009 — Epilogue

The 2009 Privacy and Security Conference is over for another year. As usual I was entreated to some interesting new ideas, issues and solutions.

But this year I’m conscious of the number of times that I left the session with a feeling that the speaker had been cut-off or missed delivering their conclusion. It wasn’t that the presenters were weak (they weren’t) but rather that many sessions ended with unanswered questions.  Such is the state of privacy and security in 2009 I suppose…

A random sampling includes:

  • How will IdM and access be effectively implemented in our hospitals and clinics? The physicians see authentication as an obstacle to delivering health services, yet health delivery organizations must have appropriate controls in place.  The CIO for Vancouver Island Health Authority had the problem well defined but didn’t give us insight as to what solutions she saw as promising.
  • When, if ever, will the US introduce effective Federal privacy legislation?  This conference has a fair number of US-based speakers and each one tells an American story prefaced by ‘up here in Canada, this is less a concern because of your privacy laws’.
  • Can government ever leverage Cloud Computing, or will data control always limit its ability to leverage the Cloud?  Nicholas Carr didn’t answer this question for us, and — given this was a public sector conference — I think most of us are skeptical that the Cloud will ever meet government needs.
  • What is the ‘killer use case’ for user-centric IdM?  Stefan Brands was technically very good in his presentation, but too often user-centric IdM is focused on the model and technology.  We get the technology now — but what are we going to use it for beyond low-value SSO?  (This topic is certainly fodder for future posts on this blog.)

Despite these loose-ends, I enjoyed this conference again this year — it was good to meet new people, kibitz with a few clients and enjoy the spring-like maritime weather.  I’m sure to be back in 2010.