Configuring Oracle and Lessons Learned

I've been in the process of working with Service Pack 2 Patch 1 running under Oracle 10g.

Strangely enough this was the first time I had ever made a serious attempt at running under Oracle. All professional and internal builds that I have ever done with NW IDM (and MIC before it) have always run under MS SQL Server. So I proceeded to jump right in and do the install. Afterall, how different could it be? It's a database that I've installed before for other applications and an application that I've installed hundreds, if not thousands of times. Little did I know...

During the process I learned quite a few things which may or may not be helpful to others configuring NW IDM under Oracle for the first time:

1. Read all of the installation documents supplied by SAP. This would have saved me a lot of headaches and about 6 hours of troubleshooting, not to mention 3 uninstall/reinstalls.

2. When installing Oracle 10g make sure that the OS user that is used to start up the database instance has the Log on as a Batch Job Local Policy Setting.

3. When configuring the ADO connections (Runtime Console) and make sure that you use the Oracle Provider for OLE DB.

4. When configuring the Java Runtime JDBC conneection make sure that you're using the odbc5.jar and that you're using the corresponding ODBC Thin Driver when setting up the JDBC RT Connection string.

5. See #1. Both points 3 and 4 were covered in the SAP install documention.

So now I appear to have a working, but empty IDM configuration. I've got running displatchers and a working Web UI. It's good to see everything up and running, and most importanly, I've learned a few lessons along the way. I've seldom had an internal, training or production install where I did not learn something, and these were ones I won't soon forget.

Next up... Installing Virtual Directory Server.

Two interesting stories

I read two interesting stories today. Hope you find them of interest as well.

1. Identity Management: More Than Just a Password
2. Changing the Face of Identity Management

A nice overview of IdM and an interesting overview of what's going on these days.

GRC & You, Perfect Together

I was glad to see Ian Glazer's blog response to my recent posting on how GRC could have helped prevent some of what happened to San Francisco's wireless network last week for a number of reasons. First off, It's always a pleasure to hear from the anyone at the Burton Group (even when we have a difference of opinion as far as GRC goes) and even more importantly he pointed out that my logic was not quite what it should have been, so I'm going to use this post to correct that.

First off, I'm hoping that Ian (and the Burton Group in general) will agree to disagree on the topic of GRC which I have discussed previously. First of all, don't think that you can look at GRC (or GRCE) for that matter as one discipline any more that you can refer to IAM as on discipline.

At its simplest level GRC is Governance, Risk and Compliance. I'd like to take some time to review how these concepts could have helped the City of San Francisco prevent this event.

• GOVERNANCE - Who in the CIO's office set up procedures to ensure that there was redundant access to the wireless systems? I find it hard to believe that the city wanted "the keys to the kingdom" in the hands of one person. How would troubleshooting occur if key players are off shift, on vacation or otherwise unavailable.
• RISK MANAGEMENT - I'd assume this did not happen since there was no Governance (under my model) being done. Did someone look through to see what the risks were? In this project I'm sure there was much attention to the people using the network, but there was little thought to who is running the network. This was the thrust of my original posting.
• COMPLIANCE - Were any procedures executed to make sure that checks were being done on the aforementioned Governance and Risk Management issues? Was anyone checking to see if there were any holes int the Governance or Risk Management plans? I'm guessing not.

I think what everyone is missing here (and I did not make very clear previously ) is that GRC is not just software nor is it one monolith process but rather a meta-process if you will that requires organizations look at all three components on a multitude of levels. If organizations do not look at the hard and soft processes there can and will be significant risks. Looking at all Enterprise projects in the through the lenses of Governance and Risk Management and Compliance is essential in today's audit and security governed world.

So in the end Ian, you're right, GRC is not one animal, but I would submit that GRC is a small herd. I'll also go so far to agree with you that GRC Controls are not the solution in this particular case, but thinking in GRC concepts and practices could have taken them a long way.

(Note: this entry has been updated to reflect the fact that Ian Glazer and not Gerry Gebel wrote the post for the Burton Group)

The Insider Threat

Much has been said recently about the Network Admin in San Francisco who shut down the city-wide wireless network last week. As I tend to focus more on IdM than security or privacy issues I was not sure if I was going to discuss the event in my blog. that was of course until I read this interview.

It made me remember that the central part of any IT Infrastructure requires trust. I recall a posting by Dave Kearns some years ago where he spoke fairly eloquently about this. (At least I think it was. Dave, care to comment) Anyway, the whole thought was that you have to be able to trust your Network Administrators.

Now for the obvious part. As President Reagan used to say,"Trust, but Verify" This means, making sure there's no orphan or rogue accounts in the systems. GRC tools will be a must in this verification.

To Virtual Directory or not To Virtual Directory, that is the question.

James McGovern was kind enough to cue me into this posting from Jackson Shaw. Jackson certainly knows his way around the Metadirectory space and is one of the smarter people I've encountered in the IdM space.

I'm a big fan of Virtual Directories from my days at MaXware and I absolutely believe that under the correct circumstances, they are a tool without equal for real time data consolidation and search, particularly when there are multiple data formats involved.

Which brings me to my point... Jackson states:

"Yes, absolutely. I think the industry will move away from a technology solution to a product solution over time. Given the "buzz" about this I am sure we will see this happen in the near-term. I certainly do not want to sell a virtual directory "product" but I do see how adding that capability to various Quest products would solve some very interesting business problems that our customers have."

I'm not sure what we'd want to move away from here. I've noticed over the years that most of the big players in IdM have had something very close to a Virtual Directory or something with lite Virtual Directory functionality and these companies have recently gone out of their way to go full steam ahead (SUN, Oracle) with this functionality. I seem to recall looking at some of the high level architectures for Access Management products and saying to myself, "gee this look like a Virtual Directory..." Given this I've also seen examples in my time where adding a Virtual Directory to an established product has solved problems of look-up, authentication and access, so I wonder why this would not be a good tool.

I've said it before and I'm sure I'll say it again, Virtual Directories, Metadirectories and even Identity Stores are merely tools. I don't think that anyone should say a tool is not fit for the job until requirements have been gathered and a competent architect had started the design process. Even then, good arguments can be made for all schools of thought. At MaXware, we commonly took turns coming up with pro and con Metadirectory and Virtual Directory arguments for all of our customers so that we could be ready for anything. These discussions always benefited our engineers and even the sales team as we looked at solutions to customer's problems.

One of the great things about this field is that there are so many great tools and people using them that there's never an end to the discussion, which I'm sure we'll have again, and again, and again and...

A Pundit's view on SaaS

I've loved reading John Dvorak for years. I haven't always agreed with him, but he has made me think. His latest article in PC Magazine fell right in with my recent thoughts on Software as a Service (SaaS).

His recent article, An Ode to Shrink Wrapped Software is something I think that anyone considering implementing IdM over SaaS should consider. Notably points 1, 3, 6, 7, 8, 9 and 10.

(Note on point 2, I'm all for compliance monitoring, but it should be on the organization's terms... not Big Brother's)

What it boils down to is , you have no control over the connection, some control over content, and no control over the back end. The pro-SaaS argument says these are all good things as they reduce infrastructure and workload for the client, and I'm even prepared to accept that. What I don't accept is lack of ownership and total control, which is most important where Identity Data is concerned.

Scholarly Reads

I had a chance today to read two very interesting documents: On Identity Analytics: Setting the Context and Identity Management in Information Age Government Exploring Concepts, Definitions, Approaches and Solutions.

The first document is a product of HP Labs and outlines an some interesting thoughts in Risk management and Analysis for C level decision makers when considering Identity Management planning, I found it kind of interesting to see this level of effort coming out of HP given some of their latest moves in the IdM space.

The second document was something I was very much looking forward to. As a Political Science Major in College, I'm always interested in reading about how Governments use Information Technology. And this is what the paper was all about. It looked at how IdM is used in government initiatives, mostly in a context of Access Management and Federation.
It's interesting to see that the IdM as a subject of academic research. I'd be interested in hearing about other similar documents. Who knows? Maybe one day I'll have a Ph. D. in Identity Management!

The reading of both of these papers will put you well on your way to your own post graduate education in IdM. I hope to see more of them.

Wrapping up on Metadirectories

Well, I think that for the moment, we've worked over this topic pretty well. Ian Yip's done a great job of summarizing all the arguments, pro and con. Somehow he even made it amusing. (Ian have you considered writing for sitcoms or Jon Stewart?)

From all of this I can say the following:

Metadirectories are not dead
The Metadirectory discussion will continue for quite some time
Virtual Directories are definitely a viable alternative

and I think that Jeff Boren said it best: They’re just tools. I know that as a MaXware alumni that's the best summation. Pick the right tool and methodology for the job.

Metadirectory = Infrastructure

It seems there's a lot of talk around the IdM blogosphere regarding the state of the Metadirectory. Even Jackson Shaw, says in his blog:

Let’s be honest. The meta-directory is dead. Approaches that look like a meta-directory are dead. We talk about Identity 2.0 in the context of Web services and the evolution of digital identity but our infrastructure, enterprise identity “stuff” is decrepit and falling apart. I have visions of identity leprosy with this bit and that bit simply falling off because it was never built with Web services in mind…

Man, but I could not disagree more. Even if one were to take the concept of Identity 2.0 as a given (see my previous thoughts on SaaS) at some point there still needs to be some sort of infrastructure needed to provide information about what's happening back in the infrastructure layer. This infrastructure layer would need to point back to the actual identity information. Matt Flynn, as always brings an interesting twist to the conversation when he bring up the use of the Virtual Directory to describe the necessary infrastructure. Incidentally this is also an approach that Sun Identity Manager takes (although they've also adopted the use of a central database store for IdM information in recent versions) Given the fact that Novell, SAP, IBM and Oracle also use some sort of central store for enterprise identity information I can't see that this concept is either decrepit or leprous, especially since if we look at the time line this makes perfect sense.

Metadirectories and Identity Attributes are the molecules and atoms of the Identity universe which came long before any concept of Identity 2.0, which as a newcomer to the Identity Universe which might wind up being Compounds, if we were to continue my analogy.

I think that Kim Cameron has a more balanced approach on this:

But you still need identity providers. Isn’t that what directories do? You still need to transform and arbitrate claims, and distribute metadata. Isn’t metadirectory the most advanced technology for that? In fact, I think directory / metadirectory is integral to the claims based model. From the beginning, directory allowed claims to be pulled. Metadirectory allowed them to be pulled, pushed, synchronized, arbitrated and integrated. The more we move toward claims, the more these capabilities will become important.

The difference is that as we move towards a common, bus-based architecture, these capabilities can be simplified and automated. That’s one of the most interesting current areas of innovation.

OK, I get it. This whole Identity 2.0 thing is about relationships and what we do with the Identity data. However there still has to be something behind the relationship, and that's got to be the atoms and molecules that I referred to before. We'll have to see if Identity 2.0 will mark not only the introduction of the relationship and federation, but also how Identity Data itself will evolve.

SaaS-ish IdM

Matt F had some interesting things to say regarding my thoughts on why SaaS doesn't work for Identity Management.

I do agree with his point that most companies "are already outsourcing IdM – they just do it on a project basis" Let's face it, provisioning development is specialized work and it makes sense to let specialists do the work. To me this is the best argument in favor of combining IdM and SaaS.

However, looking back over the past couple of years with data breaches, Identity theft, etc, I still think that it makes more sense to keep everything under one's own lock and key.

Does this solve everything or protect the organization? Absolutely not, unscrupulous folks exist everywhere and keeping data local does not necessarily confer greater protection. However, if I were the person in charge of Compliance and Risk management, I'd want to be able to look at the auditors, police/FBI, Upper Management and lawyers after an incident and be able to say exactly what I did to protect my data and not say, "well the hosting company told me they were secure..." If the organization lacks the expereince of knowledge to properly secure thier infrastructure, bring it in, would be a wise investment.