ID: awesomeness / Password: yo

E-Girl (aka my teenage daughter) is your typical 21st century teenager with a bevy of gadgets and skills to match.  She has her own phone (of course), is a blossoming food blogger and has never owned music on physical media.

E-Girl is also the hockey pool organizer.  A quick trip to, a round of poolster recruitment and she has a tidy collection of teams and picks entered and ready to go for the opening night puck-drop.

E-Girl is learning to be net-savvy and she has privacy awareness that belies her youthfulness.  (Yes, she’s endured a few privacy and Internet-safety lectures from me…)  For example, with the exception of email, she doesn’t use her last name online.

So it was with some surprise that I noticed a wee pink sticky note attached to her PC this evening… yes, a sticky note with her hockey pool login credentials on it for all to see.

You can read the damning words for yourself:

the sticky

It is shocking.


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.

Federation: SAML, Open ID and InfoCards

I came across a very succinct summary of these technologies and the scenarios they support over at Matthew Gardiner’s blog:

Information Cards provide a very elegant system for use cases which require and/or benefit from explicit user participation. With Microsoft’s impending release of supporting server side tooling, it will be an important force in Web identity management for many years to come. However, for applications for which explicit user participation is unnecessary or counter-productive – simple Internet SSO being the goal – SAML remains the best choice. OpenID’s focus remains on easing access to applications for which assuring true user identity is not really necessary.

Even better is the link to the IEEE Security and Privacy whitepaper The Venn of Identity.  Pretty much a must-read if you are interested in Federated Identity.


Passport Canada’s Retreat

Today’s Globe and Mail brought news of Passport Canada’s decision to abruptly cancel its online passport application system.  The online service allowed Canadians to fill out their passport application online, and was launched four years ago as a progressive example of e-government.

The reasons for removing the service was a lack of ‘convenience’ for passport applicants, and passwords were cited as examples of that inconvenience.  The system is being replaced by online forms that don’t require a user account and password to be used.  Presumably a user will now need to fill in the form on a web page, then print and bring the form into a Passport Canada office for processing.

Of course, Passport Canada has been under attack by the Canadian privacy commissioner and had an embarrassing security breach in late 2007.  The claim that the service was inconvenient due to the need for users to remember passwords is a bit suspicious — by this logic, we’d have wholesale dismantling of online government services and the requisite hiring frenzy to replace them with counter representatives…

A better explanation is that the agency clearly has decided that the risks of making passport data available on the web has exceeded the organization’s tolerance levels. And good for them.  Until they are able to deliver highly secured system, or reduce the amount of data accessible online, the passport application should be removed.


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’?


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.


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.


PS2009 — Sun Luncheon

Feb 3rd, 12:15pm

Lunch by invitation, and I was fortunate to be invited to dine with Sun:

Warren Strange, Senior Identity Architect
Everyday Identity Federation — Federated Identity Management is no longer science fiction!  In this luncheon we will explore how Federation is being used to solve real business problems. We will present a short case study showing how Sun Microsystems and Hewitt use federation to provide a better user experience. We will also behold the power of the mighty Fedlet!

Warren Strange provided a lunch-time talk on Sun’s OpenSSO identity provider/federation solution.  A key feature of this solution is its ability to rapidly deploy federation to smaller Service Providers (SPs) who may lack extensive infrastructure or expertise.  The product, running as an Identity Provider (IdP), allows the organization to create a small, customized ‘Fedlet’ file that can be easily deployed to provide federation capability to the SP.  While not a fully functional federation solution, the SP will at least be able to accept claims from the IdP without having to execute and manage a complex implementation. 

The second part of the presentation was an illustration of single and transparent sign-on between Sun’s employee portal and Hewitt, their HR partner.  This solution allows easy access to Hewitt by Sun staff over the web, using the same credentials they use to access the employee portal.  

During the project, the main challenges encountered included:

  • provisioning/de-provisioning of user accounts;
  • single logout; and
  • access control and audit logs (for reporting).

Of interest: because Hewitt already had an outsource relationship with Sun, the contractual agreement that was required to establish this federation was minimal.  This is in contrast to many warnings I’ve heard about the legal agreements for federated identity being difficult to negotiate.


Identity Assurance — Credential Strength

5th in a series [ <- previous ] [ <– first ]

It’s obvious that stronger credentials allow for access to more sensitive information.  And the Pan-Canadian model emphasizes that the identity-proofing portion of the Registration Processes must be equally strong to ensure that credentials are issued (and subsequently used) by the right person.

The Credential Strength in the model is a combination of the number of factors and the strength of each individual factor.  Three factors are described: something you know, something you have and something you are. These are consistent with industry standard definitions.

With respect to multiple factors, the model makes a good point: multi-factor authentication is not always stronger that single-factor.  Two weak factors (e.g. PIN and PC geolocation) may not be as useful as a single factor that is very strong (e.g. certain biometrics).

A factor’s strength needs to be assessed based on:

  • its fixity to a person, unique factors that can only be attributed to a single individual (think biometric)
  • its distinctiveness, unique attributes that by definition are distinct (think government identifiers)
  • its permanence, the degree to which a factor is permanently linked to the individual (think life history ‘secrets’)

Here is a good  quote from the strategy: “Selection of the authentication factors to be applied to a credential depends on the level of assurance required for a given transaction.” In other words, if you are protecting an asset and it requires High identity assurance, you almost certainly will need multiple factors to achieve High credential strength.

One last point: the Operational Diligence of the IAM environment comes into play here. The model defines this as the privacy, security, audit, compliance and other processes that ensure the integrity of the overall system. Environments that lack appropriate rigour cannot be used to deliver higher-value services.  In other words, if your IT shop has a weak record for availability, or has failed multiple security audits, you may need to improve the operations before implementing IAM above Level 2.

In Practice

There is a good table on page 110 of the strategy, adapted from the Identity, Authentication & Authorization Working Group (IAAWG) Guidelines, that identifies different types of credentials and their relative strength.  This table can be used to support decisions around what type of credential should be used for low, medium and high

Examples include:

  • Password or PIN — Low strength.
  • User ID and Strong Password — also Low strength.  This is because both factors are ‘something you know’ and therefore this combination is still single-factor authentication.
  • Strong Password and SMS Text PIN — Medium strength, due to two different factors being used.
  • Password and Biometric — High strength, one weak and one (potentially) very strong factor combined provide the overall strength.
  • Password, Biometric with PKI Certificate and Hardware Token — Very High strength; it would be hard to dispute the identity of the individual presenting this combination…

I’ve done some similar mapping of authentication schemes and come up with similar results.  Putting this sort of table together for your organization is necessary if you are to consistently and accurately determine credential strength for your IdM initiatives.

An important thing to repeat is that the credential strength needs to be consistent with your registration and identity proofing processes.  If these are aligned then you can, for example, allow access to an application with a High information security classification using a High strength credential.

Next: Putting it Together.

The Banks Respond

As a followup to my post last week on strong authentication, I sent an email to each of the Big 5 Canadian banks.  I was curious as to what options there were for obtaining some type of multi-factor authentication solution.

My question was: “I’m considering opening an account with your bank, and I would like to use features such as bill payment and funds transfers using web banking.  However, a password protected web banking site does not provide the same protection as strong (2-factor) authentication.  Is your bank looking at strong authentication options as a potential future enhancement to web banking?”

(The responses have been anonymized, but are otherwise verbatim.)

Bank 1 Response:

In regards to strong two factor authentication, we use three factors: the 13-digit Access Card number, the 5 to 8 alphanumeric password and the question and answer challenges previously registered with our site.

Please be assured that our web banking is a fully secure site, and your account information is protected by a number of different security protocols.

Bank 1 also provided links to FAQs, their reimbursement guarantee and descriptions of site security features (e.g. encryption, monitoring, etc.)  Note their use of the phrase ‘fully secure’.

Bank 2 Response

We are currently in the process of introducing a new service as an added enhancement to our online security.  This is a variation on two factor authentication, which in combination with our online guarantee, provides protection that exceeds industry standard.

The new service prompts for five secret questions and answers.  It then needs to know if you are on a computer that you regularly use.  If you say ‘yes’, it grabs a ‘unique identifier’ for that computer.  You can specify more than one PC.  If you login from somewhere other than your identified computers, it prompts you for the answer to one of your previously supplied questions.

Bank 2 also provided a link to other security measures and to their qualified guarantee.

Bank 3 Response

… furthering our commitment to protect your accounts from unauthorized access and fraud, an enhanced login to web banking has been introduced. These enhancements include multi factor authentication questions that add an additional level of protection, ensuring that your accounts cannot be accessed by an unauthorized third party.

All customers are now required to enrol in the enhanced login.

As with the others, Bank 3 provides a guarantee and links to other security measures.


Well, it is clear that the representatives from these three banks do not understand strong authentication.

In each case, they have indicated that adding a second ‘something you know’ to the authentication process is a meaningful improvement.  While this is better than a password alone, it does not address the issue of losing control of one’s bank account with the escape of shared secrets.  Only by selecting two different factors (e.g. something you know — a password — and something you possess — perhaps a fob) can  the authentication strength be significantly increased.  This is standard knowledge in our industry…

Two of the three did indicate that monitoring was part of their security solutions.  Intrusion dection systems certainly can detect fraud when transactions occur outside the user’s normal spending patterns.  While on vacation a few years ago, I found that my credit card didn’t work — the company had blocked it when I started using it in a different country.  This was outside my normal pattern of use.  I assume that banks have similar setups with web banking transactions, but I’m a bit skeptical as to how well they would work.

For example, would monitoring prevent an external account being setup to transfer funds?  That is something I have done in the past, and I do regularly move money between accounts using web banking.  How would a monitoring solution know it was me vs someone who just knew my password and/or secrets?

But the most bothersome thing for me is the ‘guarantee’.  While there are a number of qualifiers to these guarantees, it is clear that the bank is going to refund your money if you are phished/hacked.  But… where does that money come from?  Well, directly from the bank’s customers in the form of increased borrowing costs, credit card fees and account service fees…

Implementing stronger security, such as that offered by strong, multi-factor authentication, is likely a more cost effective and efficient way of dealing with the issue of unauthorized online bank account access.  And isn’t this what all banks require for their physical-world bank machines today — that is, don’t we have to provide a PIN (something we know) along with a bank card (something we possess) in order to access our money?  A strange contradiction, one that is worth questioning as we move more and more of our personal business onto the Internet…