Category: access

Access Governance Strategy

Identity and Access Management (IAM) projects are often initiated due to an audit finding or security review. These projects have limited management focus — really, if we’re honest about it, a compliance driven project is launched to fix a specific problem in the business. The project is expected to be delivered on time and on budget, and is wrapped after addressing a specific business need.

An Access Governance program doesn’t lend itself to this type of tactical approach. Access Governance needs a strategy, one that will help drive initiatives over the mid- to long-term. This is true even when (or perhaps especially when) an initial project is launched due to a compliance problem.

Access Governance has a longer life cycle than audit or security reviews, which are typically annual events. This is because access is something that crosses business boundaries, requires complex systems integration, and is dynamically changing as the business changes.

Business or IT strategies can help programs like Access Governance get established and funded. A strategy for access can critically assess business needs, develop roadmaps for addressing those needs, and help management to set performance measures.

When setting out to develop an Access Governance strategy, there are some key activities to be considered:

  • Know the audience — Is the CIO the primary reader of the strategy, or will it be used by multiple executives and managers?  A clear understanding of the business audience is crucial before embarking on the development of a strategy.
  • Identify relevant business goals — What is the organization trying to accomplish? What are the business goals for the next three to five years? Read the business plan and look for ways that access management can support those goals.
  • Link Access Governance to business strategy — This is the key to the process and it must be done well. Explaining how a program of Access Governance helps move the business forward is critical. But linking Access Governance to business goals needs to be realistic and defendable if the strategy is going to be adopted.
  • Identify champions — The strategy needs to be built with full support of those business leaders that will receive the benefits of Access Governance. Make them part of the strategy development process and listen to their input. You’ll be rewarded with loyal supporters of the program.
  • Develop a readable strategy — There is nothing worse than a dense, technical document passing itself off as a strategy. Strategies need to be filled with business language. They must use terms that the audience understands, and they need to be structured in a way that encourages reading. Costs need to be identified and provided in both summary and detailed forms. Illustrations and models are key, and a realistic project roadmap diagram is mandatory.

Once the strategy is approved, a program for Access Governance can be developed. Soon, priority projects will begin to deliver strategic results, and your supporters will realize the measurable benefits of having a strategy guide this crucial program.

Mike

Where you from?

Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.

I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.

This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.

I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.

I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.

But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy —  but is more aligned with client business needs.

Where you from?

[polldaddy poll=8306656]

Access Anarchy

It is no secret that enterprises run on information: records tucked away in databases, procedures retrieved from content management systems and transactions posted by business applications.  These information systems are as varied as the people who access them, ranging from highly-structured data stores to loose collections of images, files and assorted bits.  And cloud computing is flinging corporate information in ever-more places, onto remote servers, accessed by employees and customers whenever and from wherever they like.

access governance entitlements identity managementInformation Security professionals have to deal with questions that probe into information access.  On the surface, management — and their earnest auditors — have a simple question: who has access to what?   After all, access controls have been around for half a century and it is common practice to apply those controls to all types of information.  So what is the problem with these Who Has Access To What (WHAW) questions?

Put simply, security managers fear these questions because they are very difficult to answer.  And these, inevitably, then lead to ‘who gave access to whom’  (WGAW), ‘when was access granted’ (WWAG) and ‘why wasn’t access revoked when Bob left five months ago’ (WWARWBL5MA… okay, enough with the acronyms…)

Auditors know of these challenges but they are obligated to ask the questions.  It is their thing. And they don’t forget they asked — predictably they will return a year later to ask again.

Traditionally security managers would simply work with existing tools and cobble together reports based on information contained within business applications.  Once notice of an audit arrived, the security manager would direct access cleanup, export data from various systems, clean up the data, import data into a reporting tool, create reports, correct reports, format reports and submit them to management.  With anything less than 30 days lead time, this manual, inefficient process puts strain on the team and leads to errors in the reporting.

The main issues here are related to identity and entitlement management.  Let’s look at identity management first.

  • The true ‘source of truth’ for enterprise identity is the company’s human resources system.  No employee gets hired, paid or retired without HR knowing about it.   But what about temporary staff? Or contractors? Or those new employees from the company we just acquired that are in a separate HR system? The source of truth for these individuals — all of whom will have access to information — likely isn’t a single HR system.
  • Digital identities in enterprises are represented as accounts in a directory (typically Microsoft Active Directory or another type of LDAP store).  These accounts are created when employees are hired and removed when they leave.  An account is used to access network resources such as shared folders, content management systems and email. Provisioning of a user’s information directly from HR into Active Directory should be a straight-forward and high-value integration — and, sure enough, many enterprises have solved this problem already. But those relatively high-churn temps and contractors are often left outside this loop, requiring manual processes to create, modify and revoke those accounts.
  • Enterprise applications also require accounts, and these are often unique to each application or application suite.  Increasingly these accounts can be linked to the directory account, but that capability isn’t a given.  Legacy systems may have no support for this type of account linkage let alone any kind of dynamic provisioning.  And even if they are linked once, there’s no guarantee that they’ll be updated as the user progresses through the organization, experiences key life events (e.g. a name change), goes on extended leave, or, ultimately, retires or quits. As a result, gaps result that can be exploited by others who have access to the enterprise network.

Access issues are similarly challenging, and even more complex:

  • Before we get to describing the problem (even amongst ourselves), can we even agree on terms? Quick: what is the difference between an ‘access right’ and a ‘permission’? How about ‘entitlement’, what exactly does that mean?  Do you group users into ‘roles’, or perhaps you prefer ‘groups’?  Each system has its own, often arcane, language for describing what a user can access.  I have no real bias towards any one term but I’ll use ‘entitlement’ for the remainder of this article.  Entitlement is simply any form of application access right granted to a user.
  • ‘What’ is being accessed is similarly a challenge to define.  Some applications give access to all information.  Others have entitlements based on application functions or menu groups.  It is common to only have entitlements created for access to a group of records, or even a single record. Other systems have field level access controls.  And of course we have files and folders… as you can see, ‘what’ is being accessed is difficult to describe.  For now, let’s call all of these ‘information objects’.
  • These objects exist and need to be protected if we are going to keep the auditor happy (or less unhappy). Going back to our access terms, we might control access to one object using group membership entitlement – a common technique with Active Directory and network folders.
  • A business application might also use group-like entitlements that are related to job functions, but instead calls them ‘roles’.  And the roles don’t map to the same AD groups because, well, this application’s information objects aren’t used in the same way as network information objects are used.
  • Another system works from job title entitlements — only users with payroll titles can access the payroll system.  Of course, job titles may have little to do with the application’s groups or roles…and job titles change…

The result is that linking a user’s digital identity to an entitlement, then making sure the entitlement is controlling the right information object is a difficult problem to solve.  In practice, security managers delegate this responsibility to the owners of each business application.  They are given processes to follow for requesting access.  Sometimes the processes for access changes involve an email or two. Or a call to the help desk.  Or a full-fledged Access Governance tool. But in many cases it starts with a hallway conversation…

See where all this is going? That’s right – access anarchy. It seems hopelessly complicated to manage WHAW and we accept the next invite to the audit review with dread.

Over the next while, I’ll outline solutions to Access Anarchy: creating an Access Governance Strategy, having a better understanding of risk, developing standards, implementing software tools, and enhancing training. The key is to embracing the importance of Access Governance to quell Access Anarchy in your organization.

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

Managing Access — an Enterprise Issue

I got my start with identity management 20 years ago.  For much of the 90’s I installed and supported networks, and provided system administration services.  In this role I helped enterprises with creating user accounts and granting access to network resources (mostly files, folders and printers).

I’ve recently completed a couple of projects that remind me of those simpler days.  Last year I worked on an enterprise Access Governance project.  This project, for a financial institution, was a challenging to me and important to the client.  The primary driver for the project was to answer the auditor’s question ‘who has access to what’.  This organization, like so many large enterprises, needed to have an efficient method of determining which users were accessing which applications, databases and files.

Reporting on this is harder than it seems. The wide range of financial, human resource, marketing and client self-service systems means that access is granted in many different ways.  User accounts are common for enterprise systems (like network login and email) but often unique for ERP, custom or business area-specific applications.  Even if the same network account is used across enterprise applications, reporting on access (security groups, permissions, rights, etc.) is very difficult to automate. As a result, reporting on who has access to what is pretty much a manual exercise that is impossible to carry out without a significant effort.

There are a growing number of tools that are effective in supporting the type and style of access reporting required by enterprises.  But before the tools can be considered, a philosophy of strong access governance needs to be established.  According to Aveksa, a leader in access governance solutions:

… with business-driven identity and access management solutions, companies can empower the business owners to take ownership of identity and access control, provide consistent, full business context across Identity and Access Management systems, connect to the full set of data and application resources, and significantly lower the total cost of ownership

What makes Access Governance difficult is that it is a new concept that is (I think) widely misunderstood.  Executive management are uninvolved unless a breach has occurred that forces them to take interest.  Senior IT management (CIO, Directors) are feeling the heat from auditors, but have no experience with the new Access Governance tools and methods.  Managers are swamped with ‘real work’, and analysts generally consider the whole exercise to be either ridiculously time consuming or impossible.

The trick, I believe, is to get support for Access Governance as high up in the organization as is possible.  That might be the CIO level, or possibly higher if poor compliance reports or breach incidents are a priority for executives.  Only with senior support can a program be established that will deliver on Access Governance and, ultimately, start to lay the groundwork for an appropriate program.

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.

Canadian Access FederationHigher 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

SecureKey — The Interview

Andre Boysen is an Executive Vice President at SecureKey Technologies Inc., the Toronto-based technology company that is working with Canadian governments and business on next-generation identity management solutions.  With the backing of Intel, Telus and Visa (among others) SecureKey looks to make a big splash in the world of secure payments and online identity.

SecureKey Concierge is a credential broker solution that allows government web sites to use banking credentials.  With SecureKey Concierge, government sites can take advantage of existing banking credentials in a secure and privacy-protected way.

I had the chance to interview Andre last week.

Code Technology: Tell us a bit about what SecureKey Technologies is all about.

Andre Boysen: SecureKey is in the business of making online authentication easier, that’s basically what we are trying to do.  We got started helping banks to solve ‘card not present problems’ — this type of fraud went to zero with the introduction of chip cards and PINs.  But it still is an problem on the Internet – anyone finds your credit card number and billing address basically they can start ordering stuff.  It’s hard for the banks to figure out who’s real and who’s not.

We noticed that banks were moving to contact-less chips (based on near-field communications or NFC) in order to speed up things.  With NFC for quick purchases like papers and coffee, the customer just has to tap the card, no need to enter a PIN.

We saw the opportunity to use this technology to do payments on the Internet.  We have built an NFC reader and the concept is that you can have this reader on your computer, at home, and when you want to buy something on the Internet, instead of typing in a card number you just tap your card on the reader and pay that way.

One of our strategies is to get our technology embedded into all consumer electronics.  Intel is a significant investor in SecureKey and all the Ultrabooks coming out actually have our NFC reader built in.  And we are working to get it embedded in cell phones.

Code: So how does this technology lend itself to the direction you have taken with SecureKey Concierge?

Andre: So, yes, that’s a good question… Part of this is that we noticed that we are all drowning in user IDs and passwords.  And the problem for governments is that they know who I am on paper but they don’t know me in person, and when I show up on the Internet they have a hard time knowing it’s me.  The solution in the past is for the government to roll out their own credential — the current incarnation is called Access Key.  But (for higher-value transactions) that includes installing software on my computer and with all the support costs related to this, the government realized that serving me online is much more expensive that serving me in person…

The federal government’s idea was to delegate authentication.  An RFP was issued looking for proposals with 10,000,000 subscribers and at least three credential service providers.  SecureKey, partnering with three of the largest Canadian banks, was the only respondent.

Code: Why are the banks interested in this?

Andre: Their primary motivator is that they want to see identity move online. Banks want customer identities, today largely based on the provincial drivers license, to be verifiable.  With SecureKey’s model four key players will participate: federal government, provincial government, banks and telcos.  These four players have a critical role in the consumer’s life.  The federal government can set standards and leverage its buying power in a way that individual provinces can’t.  The provinces are the source of identity — birth certificates and the licenses we carry around in our wallets.  But the problem is that we don’t deal with the province very often; it’s rare that we have to talk with them and this makes it hard to authenticate online.

This is where the banks come in.  They have a very tight relationship with 98% of Canadians — they see their customers often and know them well.  By participating in SecureKey, the banks will get better digital identities, which will help them when accounts are opened.

To take this further, BC is launching new services card and drivers license with an NFC chip inside.  This is compatible with SecureKey technology and will make it easier to conduct secure transactions related to provincial programs.

What the telcos bring to this is something that Canadians always have in their pockets — their phones.  We are working to get phones and carrier networks working with the system as well.

Code: What is the typical use case SKC is looking to solve?

Andre: Any Canadian who wants quick and convenient access to any federal government service can use their bank account to gain that access.

Code: Can you confirm for us the high-level architecture? Is it primarily an identity broker service that sits between the IdP and relying party?

Andre: No, it is better described as a ‘credential’ broker service because there is no identity information passed. The government never gets the unique MBUN  (meaningless but unique number), only a service-specific number.  There is no information about the user passed to the government other than they are an authenticated bank user.  The government does its own enrolment and identity verification.

Code: Is SecureKey Concierge based on SAML?

Andre: The service is based on SAML 2.o and has support for older versions of SAML and Shibboleth.  OAuth and WS-Trust are planned.

Code: How can the service support an investigation?

Andre: It is important to point out that SKC has a privacy-enhanced design — triple blind.  No one participant has a complete picture of the transaction.

Each bank produces an anonymous MBUN for each customer. The banks will pass the MBUN to SKC during authentication. Our service will log any transactions completed in the session against the MBUN.  To preserve anonymity between services SKC will further anonymize the MBUN for each relying party service and SKC will pass a unique number called the Persistent Anonymous Identifier to each RP.

Event tracking is supported.  So let’s say CRA comes to us and says we have an event here and we need to do an investigation.  Keep in mind that the ‘handle’ we give to the RP is the Persistent Anonymous Identifier (PAI).  CRA can provide us with this number and we can provide the event logs that relate to that PAI.  If this isn’t sufficient, we can use the MBUN to go to the banks and get the details of the authentication event from them. Of course, it depends on how serious the issue is — if it is a judicial enquiry there will be more disclosure, but for other investigations we will keep the ‘privacy veil’ on.

For a compromised account, the bank is going to shut it down and the government won’t see that account again.  It is worth noting that banks have pretty sophisticated systems for detecting problems, so breaches are pretty rare events.

Code: Can you share with us the attributes that are passed between the bank and the government site? From my recent use of the service, I couldn’t tell if the bank asserted my name information.

Andre: Only PAI is passed. Name info is not passed. Note that each service (relying party) does own enrolment and may collect name.

We are all about consumer convenience, choice and privacy control. This service is very user-centric. Users are presented options to approve any information via on-screen prompts.  To facilitate this, SecureKey Concierge will have a set of templates to allow RPs to collect pre-determined ‘bundles’ of information.  The RP will use these templates to collect all the info consistently from a provincial card or bank record.

This broker concept becomes even more important as we move into sharing identity attributes.  We want to make sure we continue to support minimal disclosure.

Code: I’ve worked on citizen identity for a while now, and there is always the challenge of keeping up with their preferences and ‘life-changes’.  How does the SKC service manage changes to the citizen’s banking credentials? Let’s say I decide to switch banks, but want to keep my access to the Service Canada site in place. Is this possible?

Andre: Yes, a bank account change can be made via a the ‘Switch My Sign-In Partner’.  The process requires that you have control of both bank accounts in order to make the switch.

Code: The SecureKey Concierge two-factor solution looks to be a bit of a game changer for high-value and/or high-risk transactions.  Where do you see this technology being adopted in the online government-to-citizen space?

Andre: Enterprise authentication is something we can do. SecureKey is trying to make it easier for employees using their access badges. We see healthcare and government and finance are three verticals we are targeting, all with needs for strong authentication.

Code: How are things going? Has interest in SecureKey Concierge started to pick up? Have you seen interest in the service outside of the federal government, BC and Alberta?

Andre: We launched with the government of Canada in April, and have 15 agencies/departments online today.  Two bigger departments, HRDC and CRA, are set to launch this fall.  We expect that by the end of 2012 we’ll have the bulk of Canadian departments online with SecureKey Concierge.

As for other interest — there is nothing we can share just yet! But ‘wrapping up Canada’ (all remaining provinces) is the current goal.  We also want more credential service providers including partners from outside of the banking sector.

Code: Thanks for your time today Andre.

Andre: You’re welcome!

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