federated identity – Code Technology

Old job, new job

It has been a while since I’ve had a new ‘primary’ contract so I thought a post on the old and new is in order.

Since 2007, I’ve been the IAM Program Manager for the Alberta Government department of Innovation and Advanced Education. We assembled a development team to build a new IAM solution for the department’s growing online services. Web applications for post-secondary students were the main priority but business partner access to online services and SharePoint sites was also required.

The solution was built on top of Active Directory Federation Services (AD FS) and was developed in .Net. The services developed include self-service registration, authentication, authorization, identity proofing, access administration and reporting. We call it the Secure Identity and Access Management System, or SIAMS for short.

Today, that IAM solution has 650,000 identities, processes over 100,000 logins per month and supports 35 business applications. It supports a host of self-service features like password reset via SMS, and can deliver up to LoA 2 identity proofing.

I’m proud of the team that put the system together and very appreciative of the support I received from Innovation and Advanced Education’s management over the years. Code Technology will remain on the job with Dallas Gawryluk taking over the reins in an expanded project management role.

My new position is as a Systems Integration Project Manager with Alberta Health Services. The IAM solution on this project is quite different, and the job I’m being asked to do is already both interesting and challenging. Working with multiple teams, I am hired to plan and deliver an implementation of an enterprise IAM solution for clinical users and access administrators.

New faces, new issues — and after seven years, a slightly different commute to work. I’m looking forward to the next year!

Mike

Recent IAM reading…

I didn’t blog or even tweet much over the holidays, but I did manage to catch up on a few good posts and articles while lazing around…

The Quest to Replace Passwords — Extensive report on challenges with replacing password (HT@aniltj). The table on page 11 is worth a good study for anyone interested how various password-less authentication options stack up.
Identity Management on a Shoestring — An excellent report on how to implement IAM in an enterprise without spending years/millions. Uncanny resemblance to work I’ve been involved with in the past several years, i.e. customized implementations that are not constricted by the cost and complexity of COTS solutions.
Economic Tussles in Federated Identity Management — Another excellent paper, this time on the economic issues related to Fed ID. Points out how successful implementations occur when IdPs, SPs and users all receive benefits.
OASIS Identity in the Cloud Use Cases — A list of 29 use cases that are a solid reference for future IAM projects that involve cloud services. (HT to @RBsTweets.)
Gov’t of Canada SecureKey page — A summary of SecureKey and the Canadian federal organization and legislation that supports its implementation. Would be nice to see a link to the PIA…

These should get your new year off to a good start – happy 2013 everyone!

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

Federated Identity project

I’ve been scoping a Federated Identity Management project for a few months now. The implementation will include public users and business partners, and will support tens of thousands of users.

We are looking at a number of use cases with this design, including:

a low level of assurance with minimal shared attributes, and
a higher level of assurance with sufficient shared attributes to support a split profile.

The challenges are going to be related to privacy (the client is in the public sector) and legal issues. My focus for the next month will be to try and tackles these issues — or at least get a start on them — before we get too involved with defining the technical solution.

Mike

Fed ID and legal considerations

I recently came across this article from E-Commerce Times (via a Paul Madsen tweet) that is worth a read. It provides a good high-level summary of legal considerations for federated identity implementations. A quote:

“Many of the legal issues arise when things go wrong, such as incorrect identification, faulty authentication, or misuse of personal data…”

While it is US-based, it highlights many of the issues that we will face with Canadian implementations.

Mike

We are what we eat

A few years ago, I had a developer on my team who was famous for injecting the phrase ‘we need to eat our own dog food’ into client meetings for various appropriate or inappropriate reasons. Okay, most of the time it was inappropriate and I don’t really think he knew what he was saying…

The expression means to use the products we make, and according to Wikipedia, it was based on a dog food commercial:

The idea originated in television commercials for Alpo brand dog food; actor Lorne Greene would tout the benefits of the dog food, and then would say it’s so good that he feeds it to his own dogs.

News from Microsoft last week indicates that the company is prepared to move forward with Geneva Beta 2 as its own production solution for federation with business partners. Up to 59 applications used by almost 30 partners will be depending on Geneva for identity services.

While not earth-shaking news — Microsoft have frequently used early versions of their own products — it is encouraging to see for those organizations that are eyeing Geneva to support upcoming federated identity initiatives.

(As for the handsome fella pictured above, that would be my own brown lab, Sam… If you are reading this Sammy, your food is safe. Remember, if you are careful to always protect your online identity, no one has to know you’re a dog…)

Mike

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.

Mike

How Federation Improves Privacy

Over the past few weeks I’ve been working through some use cases and designs for a solution that involves Federated identities. It has got me thinking about the concept of authorization and how we often request more information than we need in order to authorize a transaction or session.

The essential use case is simple. Let’s use the example of a municipal library system web site. In this web site there are advanced sections that the library only wants to offer to residents of the city. An example might be a search function that allows real-time queries against library titles and directs users to the location where these books can be found.

The library’s essential problem here is one of authorization. It needs to know that the user is a citizen of the city, because it only wants the advanced sections of its system to be available to its own citizens. What is interesting is that the library doesn’t really care about the individual citizen’s identity — it is merely concerned with establishing that the online user is authorized to be granted this access.

In a traditional Identity & Access Management (IAM) system, it would make sense to create a user store, populate it (or have users self-populate it) with unique identities, then grant authorizations for each citizen to access the full web site. In this scenario the IAM would need to validate the user’s identity and collect information on them. It might also collect some ‘shared secrets’ so the user could reset their password or to later prove their identity if they called into a help desk. By the end of the registration process, the IAM may have collected six or eight or 12 pieces of information about the user.

But what if the library system had a relationship with another organization that operated its own IAM system? For example, what if the library trusted the Canadian federal government’s ePass system? In this case, the ePass system has significant user information at its disposal, ranging from birth dates to income and tax information. The ePass system also has the user’s address…

The library system could enter into a Federated Identification sharing agreement with the federal government. This agreement would allow the two organizations to share limited information. For example, the federated IAM that resulted from this arrangement could state that the ePass system could only pass the user’s first name and city of residence to the library system.

These two pieces of information (attributes or claims) are more than enough for the library system to do its job. They do not uniquely identify the user. The name would simply be used as a greeting on a screen, and the city of residence would be used for the actual authorization. If the city matched, the system would allow access. If not, it would return the user to the main web site.

The advantages to the library system are:

no need to purchase or design/build an IAM to meet its authorization needs;
no need to create, store and revoke user IDs; and
no need to collect, store, maintain and protect from hackers sensitive user information.

The advantages to the federal government are:

ability to promote its services as a single sign-on solution beyond its own web sites and business applications;
to show support municipalities that might be struggling to deliver e-government services; and
to demonstrate increased return-on-investment in an existing system.

The user also benefits:

increased convenience;
increased choice, particularly if the library system was federated with multiple parties and the user could select which system performed the authentication; and, most importantly
increased privacy protection — one less system would need to hold their personal information.

While this is a fictitious example, it is good illustration of how our governments can work together to increase efficiency, expand services and protect user privacy.

Mike