whyid (wide-eyed) ...

IdM and Outsourcing - teaser

2005-10-26T12:32:00.000-04:00

As more and more companies outsource their work, information sharing amonst the outsourcers will become more prevalent. For example, if Company-1 (C1) outsources their Desktop work to ABC-corp, and their HelpDesk function to XYZ-corp, then information about an individual must not only be present in the systems which C1 directly accesses, but also in the back-office supporting systems of ABC-corp and XYZ-corp. For ABC and XYZ to be paid for their services, they need to know information about C1's users in their asset-management systems. Otherwise how would they be able to pay for the appropriate software licenses, etc., on behalf of C1?

It may even be the case that info needs to exchange directly between ABC and XYZ on behalf of C1. For example, if C1 asks ABC to provide a desktop to Joe User, then ABC will need to send Joe User's info to XYZ so that Joe can be supported by the Help Desk.

In an outsourced world, the only thing C1 would really be responsible for is the initial "vetting" of the user and "assigning" of resources. C1 has to maintain that responsibility due to legal reasons. The outsourcer's responsiblity is to provide and support the contracted service, including any access control to the service.

This effectively breaks RBAC into two parts, with RB being C1's duty, and AC being the duty of the outsourcer. This concept can apply to more than IT resources ... for example, Benefits. C1 hires the person and assigns a role which entitles them to one of three Benefits packages. The outsource benefits provider (B0) is responsible for access control to the benefits enrollment system. The rule between C1 and B0 is setup via the contractual agreements, but must also be followed by system-level data-sharing about the hired individual. If the HR function is also outsourced, then it's back to the ABC / XYZ example above.

This means federation, and most importantly brokered-trust relationships, are essential to the business process and technology of the future. Also, the solutions which the outsourcer put in-place to support their clients will be subject to the same privacy and regulatory statutes which C1 would be subject to if they'd in-sourced their work. This may mean higher outsourcing costs long-term, as outsourcers are forced to expand their overseas environments (e.g. to support Safe Harbor), their US operations (e.g. for systems which are under ITAR requirements), and for clients who will not accept (or are too large for) a leveraged outsource enviornment. All this questions whether outsourcing or off-shoring, long-term, will remain cost-competitive.

Keep it Simple

2005-09-11T08:05:00.000-04:00

In response to Marc's statements on supporting multiple identity formats, Kaliya makes a good point:

Do you not think all this choice confuses END USERS to the point they will not adopt anything until there is one simple easy to understand way this user centric interop identity system works? Remember some of the folks using this system in the not to distant future will be functionally illiterate.

While more people are becoming computer literate, that only means they know how to click on hyperlinks, nothing more. As I blogged last month user-centric identity must be as easy to use, and as universally standard, as an ATM or Credit Card. The introduction of debit cards a few years back confused some people ... they didn't initially know it was taking money directly from their checking account. Thus, many banks started calling them "check-cards" to create the association.

The majority of this nation is not well educated ... according to the U.S. Census Bureau, nationally only 13% of those who graduate high-school go on to college. And speaking from experience, even if you are well-educated, one tends to spend any free-time living life, not figuring out how or which technology to use to buy something online.

Thus, even for the informed it must be simple and standard before wide-spread global adoption will happen. Until the Identity community gets this through their heads and stops talking about what the protocols contain, but how they're USED by the END USER, and which ones produce the best END USER EXPERIENCE, we will never make progress.

Success in Autonomy

2005-08-25T17:24:00.000-04:00

Most companies are striving to reduce total costs for operations, support, development, etc., in order to increase profits. One might then ask: "Why do some large companies, with many interior lines of business, refuse to collaborate and share"?

The answer is very simple: One can attain Success if working in Autonomy.

There are many reasons why this is actually a good motto to live by:

1) If a particular line-of-business is dependant on another in order to deliver on a committment, that lob may fail to achieve their business objectives, such as a product launch, which may mean millions in missed-opportunity cost.

2) If a lob shares another lob's infrastructure, then if there's an outage, both may be incapactiated. Isolation of business disruption (aka Business Continuity Planning).

3) Lastly, most manager's bonuses are based on achieving goals; reliance on another may not get you your bonus.

Food for thought.

Vendors, be Honest

2005-08-23T12:32:00.000-04:00

A colleague of mine recently e-mailed:

"What I've seen in the past is that COTS applications are selected based on (1) functionality fit with user requirements and (2) vendor's ability to come to terms with ... purchasing. Once those two things are satisfied, contracts get signed and the project moves forward."

This got me to thinking about the total cost for a new vendor product. Obviously, if the product is selected, money is committed. For some products, this could mean a high license fee. License fees are not the only element of committment. Integation costs, training for operations support, hardware, and ongoing hosting are all costs which need to be added. Based on researching the integration and deployment costs for the environments I've delivered, on average, for every $1 spent in licenseing, figure $2-4 additional cost before the solution is whole and in-production. This could mean alot of money in the end (e.g. if $150K of licenseing, then an additional $400K project to get it into production).

Much of the decision process for a product is based on the sales process, and statements by the vendor about the product's ability to meet the requirements. Therefore, "[it's] unacceptable for vendors to tout features during the sales call and then later say one shouldn't use those features", my colleague further wrote.

Honesty about the product and product quality is a huge issue with any large organization. Recent product quality issues have caused my client to begin considering a replacement. This will undoubtedly cause large costs for systems replacement and data migration, but my client feels it's worth it, given that they have provided the vendor opportunities to correct the problem, but it doesn't seem to have an effect.

Furthermore, honesty about a product is required else a company may not make their business committments. With regulatory requirements, product launches, emergence into new markets all weighing heavily on a company's bottom-line, if your product becomes part of the critical path to deliver, the lawsuit from fines, revenue-lost, or other lawsuits could be severe.

Morale of this blog: Vendors, be honest about the products you sell, and be honest about your committment to support them once they're sold. Else face a penalty which far exceeds the license and the deployment cost combined.

Why are my Directory costs so high?

2005-08-22T04:41:00.000-04:00

In recent months I've been hammered by my client to get my costs down. "Why does it cost so much to run a Directory!?!?!" he said, and went on to threaten "The quote I got from [an India Application House] is 10% of what you're charging!!!".

Unfortunately, many application development houses don't take these conditions into consideration ... they're focused on programming, lines-of-code, and not the operational stability of something that underpins many applications. If you were to talk to them about databases, their comment is typically "well, that's handled by the database provider". That begs the question: "So then why do you think you can do it for 10% of their cost?" They thought that Directory was a black-box item which could just be installed and runs on it's own. I can assure you, this is NOT the case in the real-world.

However, my client's inquiries did make me double-think my cost-model. I called an industry-analyst earlier this year to get an idea of what an average FTE-per-Server ratio is for running Directory environments, their answer was 1:1. That seemed high to me. I further inquired "is that for a highly available directory environment, or just a single instance on a box". The answer was "the latter".

I ran numbers, and a 1:1 ratio would've caused me to go up in price, not down. Then I though about it ... "What do I do today to support my client's Directory?" and "What are my client's biggest complaints OUTSIDE of price?" I asked.

Directory servers are like Database servers ... they're middleware components that other applciations use. However, unlike databases, they're just now maturing as a major shared component in the environment. The costs to design and operate one must accomodate for constant change imposed by the applications who use them. Unbounded searches, new ACI's, Schema and DIT extensions all lead to continuous reviews, change controls, and thorough testing. When supporting a critical application, the Directory itself becomes critical, resulting in the need for high-availability designs, strict maintenance and change windows, and back-out plans. Furthermore, the tuning of the Directory can severely impact the responsiveness of the applications it supports. Unindexed searches can lead to long response times, causing more than one application to be affected. Throwing hardware at it doesn't help (e.g. who cares if it's a v880 if you've limited your instances to 2 simultaneous connections).

My client did have performance issues, stability issues, and I had been throwing bodies at it to solve this problem. This led me to think about the end-to-end support model, and I believe three items need to be considered:

1) Engineering the initial Directory solution based on requirements
2) Operatiions and Maintenance of the Directory enviornment,
3) On-Boarding Applications to the Directory environment

To gain Operational stability of your enviornment, you need to control the inputs and outputs. This means the initial design in the 1st step has to take a "assume deny" approach, prohibiting applications from utilizing the Directory unless explicitly authorized. It also has to accomodate for the service levels and expected volumes.

Operating the environment requires stringent monitoring and proactive maintenance, looking for trends and executing minor changes to further tune and optimize performance. Applications will not notice this singularly, only at the aggregate level w/in the directory will such trends be seen.

Quite often the3rd step, Application On-Boarding, is missed. Applications, once authorized to query the Directory, could still reak havoc unless they're programmed and tuned to "behave well". Often applciation developers don't give this a thought ... they'll short-cut their programming and testing by doing wild-card searches and parsing the resultant data themselves, vs. learning how to create well-formed queries to retrieve only the data they need. To prevent this, applications must run standardized tests, developed by the Directory team, to check for unindexed searches, wildcards, too-many-threads, etc. Only if the application passes would it be deployed.

Ok, so how does this relate to costing? Well, once you consider all the functions that need to be conducted, including designing, operating, maintenance, tuning, and application on-board testing, a ratio of 1:1 starts to seem reasonable. I explained this to my client, and they began to understand the periphery of work which surrounds the initial Directory design, which the [India Application House quoting at 10% my rate] hadn't even begun to comprehend.

In the end, I did come up with a repeatable cost-model (don't ask me to share the numbers), which allowed me to be more cost-competitive AND show value to my client by explaining (in more detail than I can put in this blog) why my numbers were right, and how it improves the quality and stability of their enviornment.

The moral of this blog: It's not always about the price, but about what you get for it.

Shibboleth: Great for Unions

2005-08-18T01:43:00.000-04:00

One of the biggest concern of a low-seniority UAW-employee is backlash / ramifications for filing grievences, voting against striking, or otherwise not going-along with the "bretheren". Voting on union contracts is sometimes done by show-of-hands in large rooms. This certainly puts peer-pressure on a large majority. How does one overcome this scenario?

Enter Shibboleth. Utilizing Shibboleth technology and methodology, the UAW could be the Identity Provider and vouch for the member's identity, ensuring the member is trusted, yet providing the anonymity necessary for filing grievences or reporiting wrong-doing noticed on the job. Vice-versa, the auto-manufacturer could vouch for the same person back to the union for voting.

In summary, I foresee more applications of Shibboleth in many industries beyond schools and government, and encourage Internet2 to take this on a non-tech business road-show.

SALES: Who is your Target?

2005-08-18T01:09:00.000-04:00

At EDS I'm very controversial. About 10 months ago, in front of the Security & Privacy Practices leadership, I declared that Identity Management is NOT a security initiative.

[Arms went up, voices raised, general mayhem.]

"I can do an entire IdM program without technology, and without any relevance to security" I further claimed ... and went on with this example:

"If I get, via a letter delivered via the postal service, updated information about an individual's employment status, and I trust the letter, and my job is Cellphone service management, then I'm going to take some action, such as deactivating the phone, and saving the company possibly thousands of dollars in cost."

They argued "isn't deactivating the phone a security item". Well, no, it's not. It's called ASSSET MANAGMENT, and is a business process.

All of IdM is about business process. Security, compliance, cost-savings, and user-experience are all residual benefits depending on what business process you're addressing. The main reason for IdM is to make an organization more efficient, and more accurate about their records. One drives down cost and improves user experience, the other avoids costly penalties from failed audits.

My main client, GM, recognized this fact and has intentionally distanced their IdM organization from the Security Office. Furthermore, they're aligning with the Business, not the IT organization. Jarrod Jasper illustrated this in his Burton Catalyst speech.

So then why are so many vendors and consulting firms still selling on security, regulatory compliance, and driving it from their security solutions group to the IT organization? Go talk directly to the business instead. Don't bring a SE, but a Finance guy instead. Your sales will do better because you've now sold the solution on IT's behalf.

Real People Theory

2005-08-06T05:31:00.000-04:00

OK, so this next blog is a bit on the abstract, but related to a quote from Bob a couple years back:

"identity is people's perception of you".

-------------------------------------

The "REAL PEOPLE THEORY" was a concept that Mike Brown, Mike Maes, and I came up with back in college (during one of our late-night sessions in the "fishbowl"). In the past 15 years I've been trying to disprove it ... so far, no luck. The THEORY is very simple:

Unless you've met someone through 2 independant sources, they're just a figment of your imagination.

So here's an example ...

Many of the people you work with are imaginary. One person (call her Sally) may introduce you to another (call him Joe), who you've already met (say, at the coffee machine). While Sally is still imaginary, Joe now becomes 'real'.

However, sequence is important. If you'd first met Joe through Sally, then saw him again at the cofee machine, it's not considered an independant source, and Joe remains 'imaginary'.

So, one might ask "did Sally have to be real for this to work". The answer is No, it's possible for two different real or imaginary people to independantly introduce you to a third, and the third becomes real without the others becoming real.

-----------------------------------

Before you ask, Yes, I took lots of Philosophy in college, but No, was not my major.

In DNS We Trust

2005-08-04T15:15:00.000-04:00

If DNS is really the foundation of how the Internet runs, then shouldn't we focus on improving it's underlying security measures?

Most federation and identity technical specs make the assumption that the name-resolution was accurate (e.g. not spoofed). What if that's not true? What if DNS gets hacked?

Maybe it's time to update the DNS specifications to include a digital signature, or checksum, to ensure the integrity of the name/ip resolution. In comes DNSSEC ... the question now becomes: "when will it be in wide-spread enough deployment to be effective?"

passel ...

2005-08-03T23:13:00.000-04:00

I finally got around to reading the Passel whitepaper. Thinking back on prior readings, others have proposed a third-party data-brokers which handle all communication and selective document handling between parties (I think there was even a "notary public" PKI architecture which did very much what passel proposes).

Furthermore, it seems to me that Passel, SAML, Liberty ... even PKI ... are based on the assumption that DNS is trusted. From the Passel whitepaper:

The pass MUST contain the following information:

The fingerprint provided by the Agent in the request.
The date of issue (which MUST NOT be in the future).
The expiration date (which MUST be later than the date of issue).
The secure URL at which the Signer's service description file is located.
The value(s) requested by the Agent.
The profiles which a Target can use to verify the counter-signed value(s).

The key here is "secure URL", which loosely means "trusted hostname as provided by my local DNS provider". Now, if I compromize the DNS, spoof the IP address, then I compromize the entire foundation of trust on which pass was established. Even signatures could be compromized if the asymmetric keys are both swapped.

I met with XNS.org about 3 years ago (before they became XDI/XRI) and they got it right: Identity has to be as foundational to the Internet infrastructure as DNS. I believe one of the reasons DNS works is how distributed and temporal it is ... if you get a "non-authoritative" answer, don't trust it and look somewhere else. Passel does have a distributed nature, but it's not the only one with that claim.

I'm going to have to seriously ponder this one more ...

certificate of trust

2005-08-03T17:54:00.000-04:00

I am looking at a certificate of trust. If I give this certificate to any bank, they will not question it. It has been signed by a third-party, but they will not check this at all before accepting it and processing my request as a result of the presentation of this certificate.

What type of certificate is this? It's a certificate stating that there's a revocable trust for my estate, establishing my wife and I as trustees.

Although it's a photocopy, the bank will take the risk that the document is authentic until there's fraudulant activity. In that case, the courts will get involved, and ultimately some damages may or may not be rewarded.

We are trying to replicate this model in the digital world. The difference is this: you're not there in-person, with a photo-ID, to identify yourself to the receiving party. Safeguards must be installed for such validation.

One might ask: "Maybe one of the safeguards should be laws which can be invoked through the courts?"

My answer: "Take a look at spammers and phishers ... they're hard to find because the Internet was designed to be inherintly anonymous. Only recently was a case brought before a court. Do you really thing laws will help?"

Identity 2.0 needs to happen, if for nothing else, than to avoid the risk of reliance on the courts to restore peoples identities and thier lives.

curse of a realist

2005-08-03T17:12:00.000-04:00

andy just pointed out that those of us with day-jobs don't have time to blog all the time ... curse of a realist ... have 3 in draft, but have been busy with my deliverables due this friday

eye-dentity

2005-07-29T23:14:00.000-04:00

could it be that identity is in the eye of the beholder?

In some e-mails going around, it was posed that identity is intrinsically linked to reputation. I'm not so sure ...

There's a duality to identity and reputation in a
real-world context.  I can identify a subject based on
information, but that subject's reputation with me
might be based on the context (e.g. fingerprints
identify an individual, maybe a criminal).  In other
cases, the subjects reputation becomes their identity,
in absence of any other information.

But I think Kim said it one-better ...

Trust decisions are always ultimately local - judgments
made from the vantage point of the "relying" party.  The
relying party needs always to evaluate who is positing
both identities and reputations, and act accordingly.

one view on making user-centric convienent

2005-07-25T15:24:00.000-04:00

In his recent blog, Dave writes "Putting users in control of their own data, and needing to approve and verify it's dispersal, could cut a majority of this fraud."

The one thing I keep thinking of regarding Identity 2.0 and user-centric models is this:

* Any improvements to prevent identity theft have to be as user-friendly as credit cards ... you use it, others trust it, they track the use and distribution and notifies you of suspicious behaviour

Unless it's that easy, and that much a part of the infrastructure, people wont' be bothered unless they're a victim. I'm educated, but even I don't have time to manage my own information. I hire a financial advisor for my portfolio, so I don't have to track it daily. I use credit cards because they're convienent. I don't feel safe, but accept the risk as trade-off for the free-time to live my life.

The problem with large infrastructure is that it may become stagnant (inflexible), and thus subject to penetration (e.g. the current ATM and Credit Card industry today). Data Collectors and Identity Service Providers could be like Credit Card companies ... they might provide the convience required to make user-centric identity work, but are subject to stagnation if not managed properly.

---------------

Dave also writes: "Institutions seem powerless to prevent the fraud from happening. Or are simply reluctant to take the steps necessary. Users have a much bigger stake ... User-centric identity is an idea whose time has come, it's time that the corporate world recognized it."

Since I focus on IdM for the corporate world, it's not a matter of recognizing it, it's a matter of investment. As Jarrod Jasper said "there is no ROI, but companies are willing to pay to relieve pain ... redirecting money wasted manually cleaning-up information vs. permanently fixing the problem". Corporations are now IT-Value focused ... unless it's going to affect the bottom-line, it's not high priority.

User-centric identity will be a focus point only after it's realized to be tied to regulatory compliance and identity theft. The first corporate market will be retail ... they already focus on identity because they're incented to ... they want to know who's buying from them and that it's not fraudulant purchases.

Corporations are still wrestling with the fundamentals of user-registration, synchronizing and cleansing data, and sox compliance. They barely trust that the data they own is accurate, let alone trusting the user with owning the information. So it'll be a while before they care.

catch-22 on web services for identity management

2005-07-21T09:03:00.000-04:00

David Kearns writes:

"the era of the suite was now passing by and that the future lay with modular services within a Web services/service oriented architecture framework from one or more vendors was the wave of the future" http://www.networkworld.com/newsletters/dir/2005/0718id1.html

In the few Web Service applications I've seen written, the programmers have not transcended into a more secure means of doing application-level identification, authentication, and authorization. Some have latched onto SAML, where it's available, but that's not always the case in most corporations. Iin my industry it seems like they are using Web Service as a mechanism to re-face legacy applications. In those cases, the ID and Password for the legacy application authentication still remains embedded in the web-app. Seems to me like an identity management solution needs to exist for the Web Services and applications before IdM solutions can be built on Web Services.

Furthermore, the UDDI registry isn't holistically deployed. Seems to me like this DNS-like infrastructure would also need to exist. Who's building it? I dont' know ... guess I have more reading to do ...

what defines a highly available are Web security architecture?

2005-07-19T16:00:00.000-04:00

Everyone is saying that all the web security products have all the same bells and whistles. That's not true if you study the high-availability architectures of the products.

Most Web security Agents (Policy Enforcement Points) call back to a central Policy Server (combination of Policy Decision Point & Policy Management Point) to have any decisions made ... so, what happens when you have remote sites with slow connections, or have a high volume? Well, either the agent doesn't work, or the Policy Server dies from overload. Yes, you can horizontally and vertically scale the Policy Servers, but that only goes so-far.

Therefore, one should look for a solution which puts the PEP & PDP together. Tivoli Access Manager is one product that took this course. TAM distributes the rules from the PMP to the PDP to be executed locally. This means each application protected by the Web security domain can scale independantly, without also having to also scale any shared infrastructure. This is very beneficial for those organizations whose line-of-business have their own budgets, and don't like to pool their monies together. The other benefit is that the PEP/PDP pair (if given a small directory replica) can run fairly independantly, even if disconnected from the PMP and master Directory. Very useful for Plants in Brazil, where the link is a 56K DS0 over Satellite.

WARNING: Laws at Play

2005-07-18T01:34:00.000-04:00

ok, now that I just gave a couple data-points for justifying IdM projects, I have to put in a warning:

* The Law of Diminishing Returns is At Play

If your project is going to be multiple years in the making, be forewarned that a sharp financial leader will re-baseline the environment yearly. What does this mean? It means the savings from Year-1 cannot be applied to Year-2 ... and your job just got harder.

Example1: You implement password synchronization and save $1M in a $5M help-desk cost this year. Next year, the help-desk is a $4M problem as a result of re-baselining. Your $1M savings has already been realized, and now you need to figure out how to extend your initial investment to save more for Year-2.

Worse yet, your solution may not yeild as much savings as you thought ... in fact, it may be just the opposite.

Example2: Your new help-desk tool now costs $5ooK to operate yearly. Thus, in year-2 you now added $500K back to the help-desk, making it a $4.5M problem. In year-3 you're back to $5M, and in year-4 you're at $5.5M.

At that rate, you'll be faced with the problem of: Why didn't you just outsource this to Kuala Lumpur? You're fired.

comment on Mike N.'s cost-justifications - Productivity

2005-07-18T01:30:00.000-04:00

While Mike N. did hit the general points for justifying an IdM project, he seemed to miss-out on the value of end-user productivity. Most companies have left this as a "soft dollar" item. Manufacturing organizations, however, realize that this is a "hard dollar" item. It's tied not only to expenditure (e.g. payroll), but to revenue (e.g. if there's a strike, can't make product, can't sell product). Lost Engineering Hours, Lost Units Produced, Lost Days Worked are all units of measure which can have average salaries applied, and can be directly used to drive the ROI model for an IdM project.

comment on Mike N.'s cost-justifications - Help Desk

2005-07-18T01:25:00.000-04:00

In the BurtonGroup Root Document "Enterprise Identity Management: Moving from Theory to Practice", Mike Neuenschwander iterated many valid points for justifying IdM projects. A few, though, aren't real when considering an IT-Outsourced environment.

Many organizations outsource some element of their business, usually the Help Desk. Just because a tool, such as password self-service, reduces one type of call, does not intrinsically mean there's a savings. Quite often the contract is fixed, and instead of reducing heads, those heads would be reallocated to reducing other types of calls, or improving first-time resolution.

In short, don't assume that you'll reduce any heads anywhere as a result of technology. Those heads will most likely be re-used to fix other failing processes of your organization.

though we lie, our biometrics don't

2005-07-18T01:16:00.000-04:00

Bob's axioms were in full play at the conference last week. When people meet, they say some things about themselves, maybe more than what's truthful or accurate, or maybe not much at all. We do this all the time, but does it make us any less identifyable? I think not. The biometric aspects are still there if we choose to use them (face, fingerprint, dna). We may come to require this for any secured transaction someday, if all else fails, and if new security measures aren't intuitive to someone with barely any education.

should I be glad there's stereotypes?

2005-07-18T00:48:00.000-04:00

On the way out of the hotel at the Burton Catalyst conference, I ran into a colleague who was going to the airport as well. He handed me his keys to get the car from the valet.

Handed the keys to the valet, and he asked for the last name on the account ...

"Al-Hadidi" I said.

"You're not an Al-Hadidi" he replied.

True, I'm about as white as Wonder Bread. While his comment was rude, and while he inconvienenced me (he wouldn't go get the car until my colleague arrived), I can see the point ... most people wouldn't think twice, and might have just handed-over the car to a thief.

ok, so it's time to rejoin ...

2005-07-18T00:12:00.000-04:00

Wow, so I'm back on the net. Been a while since I did anything outside of work. *deep breath* Yeah, feels good.