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.
It has been a busy, busy past few months for Code Technology — new projects, new opportunities and a growing business. This post provides an update on our project work with, necessarily, client names obscured:
Last fall, the Identity and Access Management program that I’ve been leading for a large public-sector education organization paid some big dividends. Over the past two years my team has been building an IAM system on top of Microsoft’s Active Directory Federation Services (ADFS). The main work was actually completed over a year ago, and the first web applications with a few hundred users were launched. But in October 2009 the wider deployment started and we now have over 35,000 users, with as many as 120,000 users to come online in just over three years. By the end of 2010, we could have a dozen applications using the service, enabling access to the broader education sector in Alberta in ways that have previously been impossible.
We recently completed an IAM strategy and program development project for a very large organization (85,000+ employees) here in Alberta. This enterprise has some compelling identity challenges and high security needs. What is interesting is that we have been able to construct a strategic framework, then drive out enough detail to define individual IAM projects for inclusion into their overall information security program. I strongly believe that defining strategy without a defined delivery program as part of the report is useless — how many strategies and architectures do we see that end up sitting on executive shelves? With this project completed, the client now has a clearly articulated strategy and a practical set of projects defined in a format that is easily understandable by business and technical decision-makers alike.
We have also been working to develop the Canadiam blog and online community. So far we’ve managed to create the blog site, populate it with a few posts, create a Twitter hash tag (#canadiam) and setup a LinkedIn group. We are always open to new commenters, guest bloggers and other contributions so if you are interested in this niche slice of Canadiana, visit the site and let us know! At the very least, feel free to slap #canadiam on to any Tweets you have related to IAM in Canada.
There really seems to be an increased rumble in the IAM services space — I’ve been at this niche for over seven years and I don’t recall a time when there have been so many implementations in the works. Whether it be government, other public sector or for-profit enterprises, IAM seems to be on everyone’s mind.
In the past few weeks alone, we have had interest in Code’s IAM services from three different provinces — five different projects in total. And that’s just what a crossed my desk — there are at least three major IAM implementations being planned or being delivered in Alberta at present, renewed federal efforts to develop the Pan-Canadian framework, another major project in Manitoba and (from what I can gather) similar initiatives in the other western provinces.
There is a lot going on in the identity world. Will 2010 be the year that IAM makes a big splash across the country?
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.
• Oracle continues to invest in and share technology between Sun and Oracle products
– Sun Identity Manager will see continued investments and integration with OIM (SPML Adapter Framework)
– Sun Open SSO will see continued investments and integration with OAM (Secure Token Service)
– Oracle continues to maintain Open DS
• No change in support timelines or distribution model for Sun products
It is not really a surprise that the Oracle suite makes up the majority of the strategic direction. I recall a conversation I had with an Oracle rep from the fall — the investment Oracle has made in middleware in the past few years has been huge and it would seem unlikely they’d ditch that code. Sun Role Manager (formerly Vaau) wins and some of the other pieces (Directory Server and parts of Identity Manager) will be blended in over time.
Based on this announcement, Sun customers will appreciate no change in support and end-of-life product timelines. If they are running current versions, it would seem that there is ample time to plan for migration to the strategic platform.
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.
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.
In 2006, after three years of working with an inflexible vendor to implement immature identity and access management technology, my client asked me to document some lessons learned from the projects. I’ve done a couple of talks with these findings over the past few years and these lessons have influenced my approach to IAM project delivery ever since.
In the past few months, I’ve come across blog posts related to identity management best practices and lessons learned, such as this one from Mark Dixon. These observations mirrored my own in some ways, and differed in others, so I thought I’d put together a top 10 list things I’ve learned, including some useful advice on identity.
The only problem is that in preparing the list I cruised past 10, then 20 — and before long I had itemized 72 things that I’ve learned about IAM since I entered this niche seven years ago.
In keeping with the fashion of today, each entry will be 140 characters or less…
IAM is a tool for business; it has little to do with technology.
Business people are frequently shielded from making IAM decisions. It is not clear why this is so.
Develop an IAM strategy in 2010.
If you aren’t ready for a strategy, consider an IAM assessment so you at least know where you are at.
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(email@example.com). 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?
At great risk of dating myself, I was using PCs before the first killer app (Lotus 1-2-3) was launched in 1983. This spreadsheet software was so useful to companies that PC sales skyrocketed and a revolution was started. Killer apps have a way of shaking things up.
Email is often referred to as the killer app for the Internet, because it was the first widely used tool that required connected networks. I was using email on internal networks prior to my first Internet mail account, but the real utility of Internet-based email launched me (and millions of others) into a habit that continues to hold.
A killer app for identity management has yet to emerge, but the folks and eBay and PayPal are looking to change that. eBay’s foray into identity, PayPal Identity Services, hopes to solve the convenience, security and privacy problem associated with having dozens of online accounts. Users register by providing information that can be can verified by a third party such as a bank. The service then issues an Azigo or Windows CardSpace information card for the user to use on subsequent transactions.
The PayPal Identity Services info card can then be used by the user to share information about themselves with e-commerce or e-government sites. The idea is that the relying site does not need to collect a user profile — it can reliably collect the verified information directly from the supplied card. (Or, if it does need to create a profile, it could be automatically filled in, with the user’s permission, using data from the card.)
This type of service offers privacy protection, convenience and a more trusted transaction. The identity management industry and its customers are eager to have these solutions available to support higher-value implementations. Does eBay/PayPal have the marketing savvy and presence necessary to make this the identity killer app?
If it does gain ground, it would change the way organizations and companies offer enhanced services to their users. The ability to rely on a quality credential from another party is a game-changer: higher levels of identity assurance, more simply achieved, will allow greater value transactions and more frequent online business to take place.
Interesting blog post yesterday from Earl Perkins, one of the Gartner IAM analysts. He notes that Oracledidn’t rate the IAM product high on the list of reasons to acquire Sun— it is basically an after-thought to the acquisition. He points out that their profit motivation will drive them to keep Sun customers happy and may drive a two-product strategy going forward.
Oracle aren’t likely to make a rash decision that will reduce revenue potential and customer retention/acquisition. The message is that no matter the course chosen, he believes that this will be a 5 year transition.