IdM and Outsourcing - teaser

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

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

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

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?

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

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?

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

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.