authentication – Code Technology

Pan-Canadian Identity Assurance Model

In October 2008, I wrote a five part review of identity assurance, based on the framework contained in the Pan-Canadian Strategy for Identity Management and Authentication. At the time these blog posts were the only Canadian resource available for analyzing and planning identity assurance.

Since then a number of changes have occurred that have prompted me to update these posts. For example, an Assurance, Identity and Trust Working Group was established by the national Identity Management Steering Committee. This team prepared a report, the Pan-Canadian Assurance Model, that provides more guidance and detail than the original framework.

Having said this, the goal of the model remains unchanged; it strives to standardize identity assurance to allow for provincial and federal systems to interoperate. It is foundational to the broader Pan-Canadian framework, and is key to implementing citizen services across the country.

The identity assurance model is primarily concerned with establishing agreed-to levels of assurance and defining the concepts and terms each party need to understand. It has an emphasis on federation and looks to support risk management activities within partnering organizations.

The Pan-Canadian identity assurance model is represented as follows (click/tap to enlarge):

While this model is an important input into this blog post series, it needs to be supplemented by real-world experience. For each topic in the series, I will inject examples from my experience implementing IAM solutions over the past ten years, and provide insight into the opportunities and challenges offered by the model.

First in the series, click here for the post on Information Classification.

Mike

Should government sites use social media login?

I’ve been thinking about how the public sector model for identity has changed in recent years from one where the government body controls the credential AND acts as an identity provider, to one where the credential management is delegated to a service provider. Social media login and, at the premium end, SecureKey’s briidge.net are examples of this model.

Social media credentials from Twitter, Facebook and Google are used everyday by millions of Canadians. Why not leverage these existing accounts to access government services?

The problem I have when talking to clients about these solutions is the assumption that any credential service provider (CSP) will do. That is, a public organization can (and should) readily accept any common credential, add a layer of identity proofing, create a link back to the credential (for future access) and start counting the costs saved. After all, it is all about citizen choice isn’t it?

This isn’t as simple issue. There are some fundamental problems with using low-end credentials, such as social media logins, that need to be carefully considered when delegating authentication to a third party:

Operational Disruptions — There was a great post from the Basecamp blog a few years ago (since deleted) that described how difficult it was to maintain the link between a credential provider and the site. This post talked specifically to OpenID and how changes to the credential may not be properly shared with relying parties, resulting in support calls and manual fixes. Users would also forget which OpenID account they used, and Basecamp had no automated way to reconnect them. In the end, disruptions were common for OpenID users, support costs spiked, and Basecamp discontinued its use.
Longevity — Which social media credential providers are going to be around for the long run? What consolidations of login services or outright mergers are coming? How might the protocols for social media login change? For a public-sector service wanting to provide stable, long-term services, picking the right credential service providers is extremely difficult.
Wrong Message — Social media companies (Google, Facebook, even LinkedIn) often misbehave when it comes to privacy. They routinely run afoul of privacy commissioners and even irritate their user bases when ever-invasive features are introduced. Given the poor privacy records, should a public-sector website be encouraging the use of social media login to access government services? What are the downstream risks?
Convenience — Social media login can certainly save time when it comes to authentication. I use my Twitter account to access Level 1 (low value) services frequently. I’ll admit it is convenient and I like that blogs, news websites and the like offer this option. But convenience is far less important to me when accessing my personal information on a government website. First of all, security and privacy protection matter a lot more. Further, I don’t access these sites all that often so if I have to login (or request an automated password reset) it isn’t that big of a deal to me. What would be more useful would be a common credential for all of a particular government’s services, so that I can experience single sign-on.

So what are the benefits of leveraging a social media credential for government websites? Well, for those more trusting than me, convenience and the benefit of having fewer passwords to remember is a definite plus. And cost savings can be significant for large websites, although keep in mind that a full IAM stack is still required — the public sector website will still need to provide their own login service as not all citizens will trust an alternate credential.

Ultimately, social media login for services won’t meet government privacy and security requirements for access to sensitive information. Existing in-house systems and credential solutions (like SecureKey) that specifically address the trust issue will likely prevail.

Mike

Canadian Access Federation: A model that works

The largest and arguably most successful identity federation in the world is the network used by higher education institutions. Academics, faculty and their partners have enjoyed the benefits of single sign-on, secure wireless access and identity sharing since 2003. Interest has recently spiked in consumer login and citizen identity federation, so it is worth looking at how academia has tackled Federated ID.

There are national identity federations currently operating in over 30 countries, involving thousands of post-secondary institutions. In the UK Access Management Federation alone there are over 900 members and approximately 250 service providers. In the US, the InCommon federation boasts over 5,000,000 users.

In each of these federations, schools and service providers trust each other via a central body (hub), based on rules that are formally established for participation.

Higher education federations are focused on ‘circles of trust’. A circle of trust is a collection of organizations that, typically, operate in the same business sphere and have common traits and ambitions. For example, the Canadian Access Federation (CAF) is made up of over 50 Canadian universities and colleges, plus a growing number of cloud service providers that are involved with student services. The CAF circle doesn’t include banks, insurance companies or telcos, or for that matter, social media operators.

Higher education federations work because of these well-defined circles of trust. Participants can release and consume identity information, including a privacy-enhancing, opaque and unique identifier, because the relying parties (schools and cloud service providers) trust the identity providers (schools). And, most importantly, the users of the federation – the students, faculty, administrators and alumni – are comfortable trusting all the parties in the federation.

The identity information available in the CAF includes name, email address, institution, and ‘scoped affiliation’ (aka role, such as student, faculty, staff, etc.) This relatively rich claim-set allows a relying party to make access decisions, at least at a course-grained level of authorization.

(Note that some relying parties will still want to have enrolment processes in place to handle access to specific applications or data. These sites will need to perform additional verification steps to authorize access to services.)

The CAF standard claim-set of identity attributes is based on the eduPerson Object Class. This specification allows many sites and web applications to provide automatic access without further ‘interrogation’ of the user. As examples:

The eduPersonOrgDN claim represents the institution or organization of a researcher. It can be used by the RP to give a researcher access to a collaboration folder specific to that institution, plus a common collaboration folder that all researchers can use.
The eduPersonPrincipalName claim can be used by the RP as a key to link a faculty member to a specific record, or to a set of permissions within a web application. This in turn allows for automated provisioning to take place, with the other identity attributes used to populate the user profile maintained by the RP.
The eduPersonScopeAffiliation attribute – let’s say it is set to ‘alum’ – can act as a general course-grained entitlement, used to tailor a portal to the specific needs of alumni. For example, the portal could offer alumni special offers or encourage donations.

It is within this relatively rich framework of trusted identity claims that higher-ed federations have a distinct advantage over social media-based identity networks. Social media identities are fine for low-value transactions (personal blogs, commenting on news articles, etc.), but are nowhere near strong enough for academic and business transactions. Only within a trusted federation, where the rules of participation are clear and binding, can identity information be appropriately shared.

The CAF and its international counterparts allow for new connections and new services to be established based on trust and collaborative service delivery. It is a proven model that aspiring identity federations can learn from when planning the next generation of access networks.

Mike

Service Canada and SecureKey Concierge

Service Canada now uses the SecureKey Concierge identity broker service. This new service allows Canadians to access services using their online banking credentials. This may be the first federated identity implementation in Canada targeted at citizens. Until now, Fed ID implementations have been limited to higher education and industry federations.

Here is a screen-by-screen walk-through of how Service Canada’s site can be accessed using SecureKey Concierge and a citizen’s bank account. (Please excuse the image sizes [click to enlarge].)

1. First, from the ‘Access My Service Canada Account’ page, the link to SecureKey Concierge (SKC) is easy to locate near the bottom of the page:

Note that the government has kept their own Access Key as a login option.

2. Clicking on the SKC login brings up the SKC discovery service. It is here where you select your preferred identity provider from a list of bank services:

3. Select your bank from the list. The service then redirects to a customized bank login page (Scotiabank in my case). Note that this page is different than the bank’s regular online login page – the look, content and URL are different.
4. Note that the SKC logo is carried through to this page. Once I login — and yes, this is the exact same credential as I use with Scotiabank — I was sent to the SKC terms and privacy notice:

5. The terms and conditions can be found here. When you ‘Accept and Continue’ you are returned to a Service Canada page:

6. This page confirms which credential the user is to use, and offers to convert an Access Key credential to the SKC credential. Next:

7. Now, Service Canada lets you know what is upcoming, and informs you of various privacy and service terms. Once you get past this page, you arrive at their enrolment/registration form:

This is where Service Canada enrols you into their service by asking for selected shared secrets: SIN, DoB, an access code and your province of residence. Note that your name is not passed in from SKC, and it appears that your name is not needed on this screen to confirm your identity.

(Also note the use of the term ‘authentication’. I’d prefer they use ‘enrolment’ but I suppose for users of this service it doesn’t really matter all that much…)

8. Finally, upon successfully entering this information you are rewarded with a lengthy privacy notice and terms page:

9. Accepting terms here results in the main Service Canada service page being displayed (with links to your personal information):

In summary:

Service Canada provides an SKC login option.
SKC allows the user to select their bank login from a discovery service (page with list of partnering banks).
The bank login page is a modified version of what the user is familiar with. The user logs in using their regular online banking credential.
SKC’s terms are displayed and agreed to by the user.
Service Canada then takes over and walks the user through service-specific enrolment pages.
The user accesses the service.

Time for me to complete: 5 mins, 18 seconds.

Once enrolled using the above steps, returning to the service is simpler because the link between your bank credential and the service is maintained. This link is anonymized so that the bank is not aware of what service you accessed, and Service Canada doesn’t know what bank credential you used.

When returning to the service page, select the SKC login option. Select your bank and login. You then get access to the service without being prompted for enrolment information.

Aside from the technology and user experience, there is a lot going on here. Join the discussion at LinkedIn – Canadiam.

Updated: Click here for the SecureKey interview…

Mike

IAM for the smaller enterprise

My clients find identity solutions to be complex and costly to implement. For mature and/or large enterprises, these issues are simply a cost of doing business — and compliance or online strategic drivers are usually sufficient to fund and launch an IAM initiative.

For the smaller enterprise there appear to be two paths followed: do nothing or do it poorly. When done poorly, shoddy IAM implementations can result in poor credential management, lousy availability and inappropriate access controls.

So how does a smaller company or organization deal with identity properly? How can users be efficiently identified online without building expensive, custom solutions? What service levels and supports are possible for a login service when staff go home at 5pm? How can niche needs like strong authentication be met without excessive server license costs and complex implementations?

Enter the cloud. Cloud-based IAM service providers are maturing and there are a number of solutions that offer the smaller organization solutions. For example:

Symplified offers a full IAM service that promises plug-and-play integration with surprising depth, including support for mobile devices and apps.
PhoneFactor has a slick and secure solution for two-factor authentication that can be licensed on a per-use basis.
TransUnion have a robust identity proofing service for the critical process of confirming the identity of an online visitor.

Using one or more of these solutions allows for rapid deployment of IAM for smaller organizations. The cost savings are considerable and services levels are beyond what most companies could hope to provide on their own. There still remains integration work — applications need to be ‘plumbed’ to inter-operate with the cloud solutions — but all the heavy-lifting of designing and configuring a solution is eliminated.

The maturation of cloud IAM solutions means an increased number of companies can implement secure and compliant solutions without the long lead-times and high cost of traditional product-based offerings. In this age of rampant data breaches and increased focus on compliance, this is a welcomed development.

Mike

Authenticating those youngsters

IAM consulting for mobile authentication solution — Why can’t a device replace a password?

I had a really interesting conversation with a client last Friday. I’ve helped them to build a public-facing identity management system for access to a range of web applications. It has been running for over two years and has (literally) hundreds of thousands of users.

The chat went something like this…

CIO: As you know, our users are a bit of a younger demographic, and we’ve been noticing lately that they are having trouble remembering their usernames and passwords.

Me: Well, we’d expect them to use the forgot user ID or forgot password links on our login page…

CIO: But they don’t. Or if they do use those links it is confusing to them. We are seeing a spike in help desk calls.

Me (mystified a bit): Ummm… why is that? We use a pretty standard web page with links for these functions.

CIO: Yes we do. However, an increasingly large segment of our user base has grown up with smartphones, not browsers. They are used to apps and auto-remembered credentials.

Me (feeling elderly): Oh.

CIO: So what we need is a way to login to both web apps and device apps using just the mobile phone.

Okay, so it took a few minutes for this to sink it, but I get this. Younger users use mobile phones and apps predominantly, and the web browser experience is not the same for them as it is for us oldsters.

My own teen-age kids are proof of this — texting is definitely preferred over email, and I think I saw my 15-year old daughter tear-up last year when I upgraded her iPhone to a full data plan…

Teens, it seems, are most comfortable with a device. And that device presents information and services differently than a web page does. So differently in fact that it poses problems for authentication. This is really interesting…

There are two use cases to explore here.

The first is the identity-aware app. The app needs to authenticate the user in a way that is consistent with best-practices for protecting sensitive information. It can’t just provide access without authentication because that would be against policy and create risks of breach that aren’t acceptable. But it does need to be seamless and easy — because that is the way of the app, right?
The second case is web login without username and password… Interestingly, a user ID / password combination is only single factor (something-you-know). The replacement of this standard approach with something-you-have, i.e. a mobile device, shouldn’t be that hard. For example, a user who has pre-registered their phone with us could get a one-time code sent via SMS to the phone. They could then enter the code in order to authenticate. No more forgotten passwords, no need to remember what username I picked.

Can these use cases be met within the policies and best practices established by enterprises? Or do we need to reconsider our approaches in light of a changing demographic?

Mike

Authentication issue at heart of lawsuit

If you have followed this blog for any length of time you’ll know that I often return to issues and opportunities related to strong authentication. Last week’s news from eastern Texas is therefore of interest…

Apparently a customer of the PlainsCapital Bank lost $200,000 through one or more electronic transfers. The bank offers what they claimed to be a ‘two-factor’ authentication service. After a user name and password are entered, the ‘second factor’ for authentication is an access code that is sent to the registered user’s email address. The access code is entered by the user and their computer’s IP address is recorded (presumably to protect the session and for audit purposes). Unfortunately for the bank and its customer, the emailed code was intercepted by what appears to be a Romanian hacker and the money was stolen via an unauthorized funds transfer.

By definition two-factor authentication must include two of three different factors: something owned, something known or something inherent (e.g. a biometric). The first factor in this case is the user name/password combination, which is something known. The second factor, the access code, is also something known.

Because both of these are in the ‘something known’ category, this is not two-factor authentication. It may be stronger authentication that user name/password alone, but it is NOT two-factor.

The bank seems to have made an assumption that this code is ‘something owned’ because it was delivered to an email address that is controlled by the registered user. The problem with this is that the email account itself is very likely protected by a single factor (a user name/password) that can easily be collected by any garden-variety keystroke logger. The very idea that email is a suitable platform for sending secure access codes is odd to me — surely by now we all recognize the flaws in sending sensitive information via email?

An appropriate solution would include two unique factors combined with ‘security in layers’. A user name/password plus a code sent to a registered mobile phone would be one example. But I also like the suggestion in the article that layering good process — such as contacting the client (via phone) before such a large transaction was processed — would have also prevented this incident from occurring.

Perhaps it’s time to revisit what our Canadian banks are telling us about their security controls before casting stones towards our southern neighbours. It seems to me that without both strong authentication and security in layers, we — and our proud, large and stable financial institutions — are just as likely to suffer from this type of loss as this Texas bank.

Mike

Why invest in IAM?

I find myself being asked this question, indirectly or directly, by clients and prospective clients alike. With all the demands on IT infrastructure spending and business application development (and integration), and with all the information security risks out there waiting for solutions to be implemented, why should an investment in IAM be a priority?

From the well-respected Kuppinger Cole blog comes this view:

Part of IAM’s job is protecting data, either directly or by protecting the systems that use and store data. That is also the backdrop against which compliance regulation, both internal and external, must be viewed. That also means that it is much easier to talk with business people about “access” rather than about “identity”. The big question is how do we control and monitor access to information and systems? To do that, we need to know who is allowed to do what – and who isn’t. The only way to achieve that goal is through true digital Identity Management. Anyone who thinks he can do it by granting rights and approvals based on IP addresses or MAC numbers is seriously kidding himself.

It strikes me as odd that there are still IT and information security professionals that believe IP and MAC access controls are sufficient, but it appears that this myth persists in enterprises.

Worse, I believe, is the view that the home-spun access control that has been built into legacy applications is ‘good enough’. Why replumb our existing enterprise and customer-facing systems with a new-fangled IAM solution when we have the problem solved already?

This is a powerful myth that can be hard to overcome. But compared to application-specific controls, IAM has some significant advantages:

Compliance — Organizations today must comply with legislation and their own policies. The access control sub-systems built-in to many legacy applications are simply not compliant, and it may require significant rework and duplicated processes to remedy. Conversely, an enterprise IAM solution can be implemented to be compliant from the start, and a single set of processes can be created to maintain identity and access information.
- Example: Privacy Impact Assessments (required in Canada for all projects that deal with personal information) can be done once and shared across all applications.
Audit Support — ‘Siloed’ access control systems are very difficult to report on at audit time. With IAM, consolidating information is much easier and correlating a user’s access through multiple systems can be achieved.
- Example: A single reporting tool or sub-system can meet most (if not all) auditor reporting needs.
Help Desk Efficiency — With IAM, a single console for Help Desk agents can be implemented for end-user support purposes. Naturally, a single system will offer improved efficiency and better service to end-users than multiple, application-based systems.
- Example: Help Desk lookup tools can be standardized and easily learned by new staff. Password policies become consistent. Access to multiple systems can be suspended or revoked from a central point. Service to end-users improves.
Leverage and Speed — New applications, especially e-business and e-government systems that have to deal with privacy and security issues, can be readily designed around a common IAM solution. Deployments can be rapid due to standardized interfaces and re-use of common templates. Processes can be leveraged, not rewritten from scratch, making the transition to a production environment more seamless.
- Example: Strategic applications that need to be implemented ‘right now’ can be rolled-out quickly with high security, advanced features and appropriate user privacy protection. Decisions can be made with confidence that the common IAM solution will meet both enterprise and line-of-business requirements.

Real IAM solutions offer real value, making business case development easier and more compelling. However, widely-held myths about the effectiveness of network and application-specific controls need to be dealt with if broader IAM implementations are to be approved, funded and supported.

Mike

v[ep_!)7@=2n9B

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.

Mike

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.

Mike