Ping is launching its second product

Andre Durand's company, Ping Identity, is launching its second product (Ping Trust, I believe it used to be called Ping STS...but could be wrong) during the RSA Conference later this month.

http://www.pingidentity.com/pingtrustparty.html

Seven Deadly IdM Risks

Seven Identity Management Implementation Risks
Mark G. DixonJan 25, 2006 - Show original item


I taught a class today addressing best practices in Identity Management implementation. Part of the presentation was entitled "Seven Common Risks." I lobbied to call this "Seven Deadly Risks," but some folks thought that title was a bit over the top. Nonetheless, here are seven risky behaviors that could kill your Identity Management project.
Poor Pre-Project Preparation
Poor Requirements Definition
Large Initial Scope
Inexperienced Resources
Poor Project Methodology
Scope Creep
Not Using Available Support

Contention with Law #1?

IBM's Bob Blakely put up a post recently on the Absurdity of Owning One's Identity, where he comments on Kim's first law. Interesting stuff. He also has some really interesting insight on the topic of identity being subjective. Good read.

Notes on Laws of Identity (Part 2)

Here is the second part of note on the Laws of Identity. Enjoy.



1. "Laws" in Laws of Identity should be understood scientifically - hypothesis about the world resulting from observation which can be tested and therefore disprovable. Laws shouldn't be understood here from moral or legal perspective.

2. Digital Identity is defined as a set of claims by one digital subject about itself or another digital subject. A digital subject is a person or thing represented or existing in the digital realm which is being described or dealt with. Finally, a claim is an assertion of the truth of something, typically one which is disputed or in doubt.

3. Examples of claims:

• A claim could convey the identifier. ("jdoe" is the username for John Doe)
• A claim could assert that a subject knows a given key.
• A set of claims might convey personally identifying data.
• A claim could propose that a subject is part of a certain group.
• A claim could state that a subject has a capability.

4. Our definition leaves the evaluation of the usefulness (truthfulness) of the claim to the relying part (or the party to which the claim is made). Evaluation of a digital identity thus results in again producing claims. Matters of trust, attribution and usefulness can then be factored out and addressed at a higher layer in the system than the mechanism for expressing digital identity itself.

Notes on Laws of Identity (Part 1)

1. Problem Statement: Since there is no identity layer on the internet, various "identity one-offs" emerged to fill the gap. This has led to two problems: (a.) No consistent comprehensible framework allowing users of the internet to evaluate the authenticity of the sites they visit (b.) Lack of a framework for controlling many aspects of their digital existence.

2. Phishing and pharming are two of the fastest growing segments of the computer industry, thereby threatening the trust of the people to use the internet ...thereby limiting the potential of the internet. One huge hole would be the prevention of reaping the benefits of web services.

3. It's hard to add an identity layer to the internet because digital identity is related to context, and the internet is experienced through a thousand kinds of content in at least as many contexts. So the many attempts to add a "layer" in fact work great for a specified set of contexts, but not to other contexts.

4. Therefore, the emergence of a single simplistic digital identity solution as a universal panacea is not realistic. The diverse needs of many players demand that we weave a single identity fabric out of multiple constituent technologies.

5. This is going to be damn tough, but history has proven that things like this are acheivable. Two examples: (a.) Way back when, apps had to be "aware" of specific hardware and code "to it". Over time, a software layer emerged to abstract the specifities of a given hardware. Device drivers enabled interchangeable hardware to be plugged in as required. Hardware became "loosely coupled" to the computer. (b.) Way back when, apps had to be "aware" of specific network devices. Add a layer of abstraction and voila! TCP/IP allows apps to work without knowing a darn thing about the underlying systems (Token ring, ethernet, blah blah). We now "add" wireless to the mix, and no apps break! great stuff.

"Notes" IdM Papers

I've decided to dedicate some time to write "notes" or reviews of some well-known white papers on identity management that focus on the laws or theory of IdM. Here is the list of papers I'm going after:

1. Laws of Identity, Kim Cameron
2. Microsoft's Vision for an Identity Metasystem, Kim Cameron
3. Introduction to the Persona Model, Radovan Semancik
4. Enterprise Digital Identity Architecture Roadmap, Radovan Semancik


After these, I'll work on publish some notes on my following areas of interest:

1. SAML 2.0 Spec
2. WS-Fed Spec
3. LID
4. XDI/XRI and i-Names
5. SXIP
6. YADIS

Let's see if this ever happens. Hopefully it does.

Interesting Blog on Raising Series A

http://blog.meebo.com/

MIIS and TDD (part 2)

So from the last post.
So, its obviously important to have version control.
But its just as important to have test cases. And whenever there is a decently large system, its important for the test cases to be automated. (After you've wasted half a day or more manually running through test cases, you really begin to appreciate 10 minutes of an automated test case run.)

How should test cases be written for MIIS? To answer this question, we gotta think a little bit about the differences of an MIIS deployment vs. software development. We've done a bit of thnking around the similarities, which is great. But the differences will give us a clearer understanding of how to approach writing test cases for MIIS. Next blogs should cover these differences.

MIIS and TDD

TDD (testcase drive development) is an approach to coding, where testcases drive code. What that means is that you write a testcase for your code, then code to make the testcase pass. An example is an (math) addition method. So, you have a math class of some sort that does simple addition, and you want to test it. Your test case takes 2 and 3, and using the addition method from your class, you should get 5.
First comes your test case. It fails because you havent really written the code that does it yet. Then you code to make the testcase pass. That's the crux of it. The benefit of this is that when you have a whole lot of code, and dont remember what does what and how...you could, let's say, refactor and run all of your tests again. If they all pass, then the refactoring effort was done well, and didnt change the way your code works.

So...what does this have to do with MIIS? In complex MIIS deployments, data flows can get so complex that you dont really remember what does what. You could develop a whole lotta helper classes that your rules extensions utilize. At some point in time, you decide make a few changes for a new IAF for example, and all of a sudden - your provisioning logic breaks. Woops!

But you already put it into production! now what? hmmm...

more on this later.

MIIS Deployments vs. Software Development (Part 4)

Another similarity:

refactor-ability. not sure if thats a word. basically, a "modular" design that allows for changes in business logic that won't lead to redesigning the entire system.
now, using the word "modular" when it comes to data flow in MIIS seems a bit odd. but there are design considerations that would lead to a "flexible" system that allows for changes in business logic that won't lead to breaking everything.

SO. I think i'm going to quit at part 4.

European Laws - and Identity

http://www.cnn.com/2005/TECH/internet/12/09/cyber.cafes.names.ap/index.html

MIIS Deployments vs. Software Development (Part 3)

Both MIIS Deployments and Software Dev are iterative processes focusing on client satisfaction. Well, most (if not all) consulting work is client-centric, but MIIS and Software dev are from another perspective.

They both have a specific end product that the client will (typically) know right away if he/she is satisfied or not. For example, a client uses a web app aimed at managing site content will know right away if the site suits their needs. After a day or two of use, client satisfaction will become obviously clear to the consultant. There will either be praise or blame. The same goes for MIIS deployments. If users are not being appropriately provisioned, there will be complaints. Usually, the day after going live. :)

So, there is, yet another, similarity between MIIS and Software dev.

Radovan Semancik's Identity Management Predictions 2006

Identity Predictions for 2006 and beyond


The beginning of a new year is usually a time for planning and predictions. I allowed myself a little fun to make these predictions (and hopes) about the "identity" techologies.

1: "Identity" becomes mega-buzzword Every other company will be "identity-focused". More and more products will be "identity-enabled". You will hear more about "identity" in mainstream media. And most of the people (include those in "identity-focused" companies working on "identity-enabled" products) will know absolutely nothing about what this "identity" is all about. The "identity industry" will be hyped. The stock prices will rise too high to be realistic. Many startups and aquisitions. Some really valuable, most of them average, and some just empty shells with good marketing. As usual. 2: Many "identity" mistakes happen, but it will take a while for them to be seen. It will become apparent, that "user-centric" identity is not that easy. Not many of the "identity folk" will ever admit it, but they will know, sooner or later. The naive global (URL-based) "identity" systems will proliferate for a while, but (hopefuly) not for long. Most of the current "user-centric identity" systems will need to be redesigned, limited to specific purpose or will just die. Maybe not in 2006, but they may eventually face the fate of X.509. We need to see at least one more generation of "identity" system to get something really usable. Similar situation will be seen in the real world. Many "national ID" and "national database" system will be proposed only to learn that the technology or the approach is not yet good enough. If you ask me who will "win" on the Internet, I think that it would be something based on WS-Trust. Or maybe something similar to WS-Trust that can be used both over SOAP and REST. But that will not be apparent in 2006. And I think (a hope again) that the "claims" will be SAML-based. 3: More client-side identity implementations will be seen. As of today, we have almost exclusively seen only pure-web server-side "identity" solutions. As the technology starts to mature, we may see more of a client-side support for "identity". Microsoft "identity selector" (InfoCards), and Liberty-Enabled Client Profile being the first signs, but I believe there will be more activity. Maybe Mozilla community will be drawn to "identity". Or maybe we will see first "identity selector" for Linux? 4: Enterprise Identity Management will spread through Europe. This one is more a hope than a prediction. European companies are quite late adopters of Enterprise Identity Management technologies. I think that it will change, but the change will be quite slow (especially here in Central/Eastern Europe). There will be a bit more "identity" projects in 2006. But the hype wave will come with full strength in the following years, powered by regulations such as Sarbanes-Oxley or EU auditing rules. 5: Spam, phishing and pharming will get even wilder. This is a safe bet. Nothing can be done to help in this area given current technology and only one year of progress. Spam will continue unhindered, heuristic methods being the most effective. The community will start to design the replacement for SMTP, that will be based on identity and social networking. It will not be seen as SMTP replacement at first, but will evolve to that. The phraud will move on beyond its current primitive techniques. Phrauders will find advanced methods, just like putting pharming functionality into viruses and worms. Strong auth will help a bit, but will not stop the most sophisticated attacks. 6: Strong authentication will get integrated with "identity". Authentication and "identity" may not be the same, but they cannot be seen as separate. Authentication companies will look at "identity" technologies as a way to sell more of their products. And the authentication products will comoditize. Maybe it will not happen in 2006, but we will eventually buy SecurID tokens in hypermarkets. 7: We will see attacks targeting legacy "trust" mechanisms. Ever seen the list of "trusted" certificate authorities in your browser? Ever wondered how difficult is to get a false certificate from any of these authorities? Well, I expect that someone will try and succeeds. There was not much motivation yet, as it was easier to steal a password. But once strong auth will be here, man-in-middle attacks will be popular again. And given the cumbersome and not-much-functional revocation mechanisms of X.509 implementations, these attacks may get pretty effective. The year 2006 will be long over when people finally realize that the authentication must be mutual, not only one-way and that the "strong auth" is not a panacea.

More on my previous post

OK...so what are the similarities?
Alot. Im not going to let them all out in one shot. Little by little. So I have an excuse to have more posts. The honest truth is...I don't know if I have all that much to say. So, I'll have to spread it out over alot of posts.

OK. A similarity: Both have business logic. In this sense, it's not like network design/arch.

MIIS Deployments vs. Software Development

Since this is an IdM blog, I'd better start doing some IdM blogging.

OK - here is where i go tech:
MIIS deployments are not your typical middleware type deployments.
So there.

More on this later.