I like to refer to Identigral as "she." Perhaps it is a subconscious reaction, similar to naming a car Clarice or perhaps not, it is a woman-owned company after all. She is celebrating her third year today and I thought it might be a good idea for the blog to recap our top 11 greatest blog hits. In order of decreasing popularity, they are:

1. The Rise of Suncle, Volume 1. The first article in the 3-part Suncle series looks at the Oracle acquisition of Sun and drills down into their respective identity and access management product lines, taking up identity and role manager products at both companies. When I started writing the Volume 1 post, I naturally thought of Volumes 2 and 3 but after finishing the post, I realized that it would be better to use functionally relevant titles. Thus, Volume 1 should have been named "Identity Administration" but just like you can't remove a product feature once it's released, you can't retract URLs once they're published. (Yes, I know about HTTP redirects and URL rewrites but I don't think of either as an ideal solution).

2. The Rise of Suncle, Access Management. Second article in the Suncle series that talks about Sun and Oracle access management product lines. Many mentions of fishes as in "sleeping with the fishes". Note to self: avoid watching "Sopranos" before blogging.

3. Authorization in Oracle BI Server (OBIEE). Oracle BI has been widely deployed in various incarnations so the number of visitors to this post is somewhat surprising. This fairly straightforward summary of how to go about integrating the BI Server with an external identity repository for the purpose of authorization proved to be very popular. Contains a bonus feature on how to solve the authorization problem with Oracle Identity Manager. Two for the price of one - read and save!

4. The Rise of Suncle, Directory Services. Third article in the Suncle series, narrowly losing to OBIEEeeeeeeeeeeeek (couldn't resist, sorry). This one is dedicated to (surprise, mystery, shock) directories on both Sun and Oracle side. I said that Oracle should keep Sun DS and make it available alongside Oracle Internet Directory (OID) but I now believe this was an optimistic assumption. My revised prediction is that eventually only OID will remain standing, at least as a commercial offering.

5. Generic Connector and the Temple of Doom. Appropriately titled post on connectors. This stream of consciousness could have easily rivaled Charles Dickens' "Great Expectations" and might have been serialized into a comic strip had I continued waxing poetic. There's enough material to be mined in this thread to sustain a small army of journalists writing for many tabloids. I can see the headlines already - BREAKING NEWS: CONNECTORS AND ELVIS DISCOVERED ON MARS, BOTH ALIVE AND WELL

6. Identity Management Is a Lifestyle, a guest blog by Tom Ebner. While having been out in the blogosphere wild for a short period of time, the meteoric rise in popularity of this blog can be easily explained by its manifesto-like message. From one man's 7 years of experience in leading the creation and deployment of IAM infrastructure and services for a Fortune 500 company to a 1-page collection of rules on how to succeed with such an effort. It moved up to the #6 in our Top 10 in just a few weeks.

7. Provisioning Active Directory - Best Practices. A guest blog by Martin Sandren talking about how to deal with that wonderful Microsoft product/service/pile of stuff we have come to know, cherish and love. Memo to Martin: when is the book coming out? Suggested book title: Active Directory: Alien Mummy Goes On Rampage! If you take me up on the title, it'll be placed next to other good literature at supermarket checkout counters and you'll be guaranteed a financial windfall. Don't forget to share the royalties!!!

8. The rise of Suncle: Solaris, Java, Ripple Effects. Apparently I had more to say about Sun/Oracle marriage. Quelle surprise.

9. Will the Real Oracle Identity Management Please Stand Up (Part III) . The first two parts of this 3-part series were a lengthy prologue to the blockbuster revelation in part III. Here I explained the difference between "legacy" Oracle identity management stack (OSSO, OAS, OID) and the "current" stack (OIM, OAM, et al). With 11g shipping, I will need to do a Part IV soon.

10. Virtual Truth, Chapter 1. I ran out of parts and volumes so I had to start using chapters as my sequencing device. This blog post was my paean to virtual directories as a neat architectural solution for whatever ails you (errr, enterprises). I continue to be impressed with Oracle Virtual Directory, it's like a Swiss knife that can slice, dice and cook you breakfast.

11. The Big Bite. A limerick commemorating the acquisition of Sun by Oracle, this is one of my better attempts at worldwide fame and I could not leave it out of the Top 10 so I changed the rules and called it Top 11. Dear Larry Ellison: I know you've read the limerick and you liked it so I would appreciate an invitation to the next regatta. Please do remember to bring champaigne and caviar. Toodles for now, Deb.

Honorable mention: Opt Me In, Opt Me Out. An essay response to a question posed by University of Rochester's Mike Conklin on his blog, this post deals with an identity management solution to managing the membership of a mailing list.

After the Suncle series covering the Sun/Oracle identity and access portfolios, one of the most popular posts on our blog was an article talking about best practices for Active Directory provisioning by guest blogger Martin Sandren. To continue with the thought of providing interesting (and different from our usual ruminations) content I am pleased to introduce Tom Ebner as our guest blogger.

Tom Ebner has spent the last 7 years leading the creation and deployment of Identity and Access Management infrastructure and services for a Fortune 500 financial services corporation. Tom successfully delivered IAM in the real world despite the challenges of new technology risk, changing organizational objectives, scarce resources, and vanishing budgets. Tom is now helping other organizations to plan and execute IAM deployments.

----

Do you like solving tough problems? Enjoy working with new, evolving and often immature technologies? Like being dependent on new business processes and multiple data sources over which you have no control? Welcome to Identity and Access Management! After 7 years spent creating and deploying Identity and Access Management infrastructure and services for a Fortune 500 company, I recently took time to reflect on the experience. As a colleague of mine often reminds me – “Identity Management is a lifestyle”, minus the yachts and Rolls-Royces.

I started with a basic corporate directory and evolved to a full-blown Identity and Access Management infrastructure and services. We went from web single sign-on to provisioning of accounts to role management and entitlements. Here are a few things that I learned while living that lifestyle.

Rule #1. Understand the problem and the opportunity One of the smartest things we've done was to approach IAM as a fundamentally data-driven domain, even though the problem was initially framed in the context of security. Audit findings created high-level awareness of the need to do something, but the concrete dollar value we delivered was based on improved operational efficiency and better customer service. For example, the data required to answer the access control question “Is system access commensurate with job responsibility?” can also be used to route a customer call to the appropriate customer representative. We found we were able to deliver quantifiable business value using this approach.

Rule #2. Assess the quality of the identity data We were fortunate to have a unique internal identifier that had been established for each member of the workforce and this made it easier to correlate data across multiple sources. Having a single, preferably opaque, unique identifier is critical but not necessarily sufficient. Other attributes may be required for correlation but data sources may not have these other attributes or may not assign the same meaning to them. Furthermore, if you have an identity service that provides identity-related information to the rest of the enterprise, it is desirable to extend the data quality rule to each data attribute you expose. While the Identity services provider may not be the “owner” of the various attributes, the identity services are used by the enterprise as an authoritative source and you as the provider will be held responsible for any quality issues. Ensure your authoritative sources understand their responsibilities. We spent a lot of time educating and influencing in this area.

Rule #3. Create a strategic technical vision ..and stick to it! Early on the team created a one page vision for the identity lifecycle. We started with Burton Group’s representation and customized it for our business. This is the familiar on-boarding / registration, provisioning of accounts and associated entitlements, job change and transfer, and finally termination and de-provisioning cycle. We made it speak to our specific business process goals and systems. It was critical to help executives understand the “what” we were planning to deliver ...which brings me to the next rule.

Rule #4. Get (and keep) an executive sponsor IAM is an infrastructure play and with no readily discernible business value as such it is tough and risky from a sponsorship perspective. It involves change to operations and it is not a revenue generator BUT it's a critical enabler. As time went on, it became seen as essential to security and compliance but this wasn't true in the very beginning. You will need an articulate, visionary sponsor who can bring visibility, business reality, and funding. Don’t minimize organizational inertia and tension between different layers. Organizational communication and alignment of objectives still required constant time, attention, and adjustment. Make sure the overall program goals are in sync across security policy, access administration, operations and technology groups.

Rule #5. Build a great team I’m a huge fan of small, smart, creative, and collaborative teams. My core team included an architect comfortable with enterprise architecture and hands on product configurations, a data analyst (DBA quality but with business analyst savvy), a technical lead (expert in the IAM product suites), a business analyst (highly analytical and business relationship oriented), a security expert with software development background and PM skills, and a production operations specialist. We also had an offshore team of skilled production support and software development folks. The breadth and depth of specialized skills required should not be underestimated. Allocate time and money for training and mentoring of staff and offshore teams.

Rule #6. Add great partners to your team In keeping with the theme of “Identity Management is a lifestyle”, you will need significant help from product vendors and professional services all along the way. Make good choices...or they will come back to haunt you. You want partners that help you think creatively about solutions, will take the time to understand your use cases, and will stick with you in a long run. In my case, I worked with product vendors (from major players to startup), IAM services specialists, and offshore vendors. While deliverables are critical, I always looked for partners that I could work with. These relationships paid off when the going got tough.

Rule #7. Create a strategic technical architecture Another key to our success was our selection bias and approach to architecture. We created a domain boundary and clearly articulated what services belonged inside or outside the boundary. This was extremely helpful when it came to detailed design and product selection over the years. It also helped with our internal discussions in the technology enterprise. State your design philosophy. Our bias was buy rather than build, and never do both. We only created custom applications where no product fit our requirements. This meant we created our own White Pages presentation and custom developed web services to expose our identity info. This gave us the ability to control access to domain data and enabled us to control the release process (vs. being dependent on a vendor release schedule).

Rule #8. Deliver something valuable to the business Do it fast, often and preferably yesterday. For us it was making high quality data about the workforce available via a friendly web interface and via secure web services. This allowed us to deploy web single sign-on to virtually all intranet applications and eliminate many individual stores of identity data, providing tremendous operational value as a result. These early successes gave us credibility and paved the way to funding for the next steps… Be opportunistic. We kept our ears open for business problems that could be solved by our services AND would further our strategic vision. For example, instead of a large cross-enterprise role-based access control (RBAC) project, our philosophy was to avoid roles unless we had a very strong business partner with a very well-defined and limited number of roles to implement.

Rule #9. Manage your risk. IAM is a program or a portfolio with inherent risk. Monitor and manage your risk across the portfolio. As with all technology projects – especially those in new product or process areas – be sure to have a plan B (and a plan C, plan D, etc…). While our program was very successful overall, we did encounter significant setbacks in certain areas. One of the biggest lessons I learned had to do with provisioning accounts and entitlements to the mainframe. In this particular area we had a lot of heartburn and not many alternatives so our risk to contingency plan ratio was disproportionately high (high impact with high probability with inadequate contingency plans). While it is often convenient to think that in a buy vs build scenario, if you buy a product the risk has been offloaded to the vendor, this is a fallacy. You own the risk. Spend the time and energy to go through what-if scenarios and be fully prepared to switch gears if and when needed. Balance the opportunities for funding with product and business process maturity. Choose incremental steps carefully.

Rule #10. Understand and communicate “What does success look like?” Manage your stakeholders. Create an annual business plan with clear objectives, expenses, strategic vision (business and technical), and be clear about what is “not going to be done”. I also kept a slide that listed accomplishments in the prior year and to date. I carried this everywhere and used it to keep a persistent message flow on our accomplishments, plans, and value delivered. Never underestimate the communication required for a successful IAM program. It is not an easily explainable topic to most business and/or technical execs. Whatever amount you are currently doing I assure you that you need to do more!

Thanks to Anil John's tweets, I've been alerted to National Institute of Standards and Technology (NIST) workshop on Access Management. Having worked for DARPA a long time ago in a land far away, I am not afraid of terms such as Plenary Session or Hotwash,they make any proceeding seem important and rife with danger. Someone abused their access privileges or shared a password? Call the NSA to erase him. (Let's see if there are going to be any information security incidents after that..)

I know that some are not aware that NIST does good work in the information security realm. Among other things, they publish a series of documents called Special Publications (800 series) that cover many basic and not so basic security topics. While not particularly groundbreaking, they're thorough and vendor neutral and can serve as a good overview of technologies or approaches for just about any information security initiative. Unfortunately, the technology landscape evolves at a fast clip and there's a fair amount of dated material, ranging from slightly dated to ancient. Caveat emptor.

What I found interesting is a presentation by NIST's David Ferraiolo that talks about a universal Policy Machine or, to be more exact, a universal access control stack that can slice, dice and cook you breakfast. As the presentation notes, the main problem with access control today is very simple - the implementation is nothing like the policy. In other words, the policy might be a complex document with legal nuances but by the time the requirements filter down from the original policy document through the business to IT to implementation to delivered result, you might as well have asked for a submarine with nuclear warheads and instead gotten a toy hammer. The presentation refers to this transformation as "dismal state of affairs". (Something is rotten in the state of Denmark!) The reasons for the policy/implementation gap are many; the author cites lack of interoperability (i.e. a challenge in having application X and device Y and operating system Z all getting their "direction" from one central decision point) in heterogeneous environments as one key problem.

Furthermore, access control as defined in the paper is broader than just access to resources. It includes unauthorized dissemination of information, e.g. via a copy and paste into email and other out-of-band actions involving endpoints such as flash drives. From the author's perspective, access control should encompass the entire computing stack and then some - OS, devices, applications and data. To this end, the author proposes a universal Policy Machine that has "just enough" expressiveness in the "language" used to implement attribute-based rules so that this Policy Machine can become that one decision point all applications, devices and operating systems will use for access control. Reading this I had a science fiction flashback and my brain came up with this as a visual representation of a Policy Machine (hint: it zaps you)

The presentation closes with a promise of a working prototype of a Policy Machine that covers files and Open Office suite of apps, including copy and paste. In my next blog I will attempt to build the Policy Machine from stock parts, similar to what Jonathan Godwin (my personal hero) does with car engines.

...but perhaps it should be. A properly fortified island with double moats, crocodiles (or cheerleaders), molten lead showers, Spartan warriors and of course artillery straight from Guns of Navarone . (I don't know why you need artillery if you have crocodiles but I wanted to add it just in case. As the ancient Finnish proverb says, "backups never hurt").

In many an enterprise you'll find a network architecture where a lot of effort has been spent on protecting the perimeter, separating nice, shiny, internal TCP packets from mean, dirty and virus-laden external packets. (UDP packets are always lost and confused, no need to filter them out). As Gunnar Peterson writes in his "There Are No Firewalls" blog entry, imagine that there's no firewall separating inside from the outside. What would be the potential damage to the business assets previously thought safe? This is an excellent Gedankenexperiment for any enterprise architect but it's particularly interesting to examine in the identity and access context.

Firewalls are breached because the attacks evolve faster than perimeter security products. Even if the product has adequate protection against some very sophisticated threat, it's far from certain that it's configured and installed (and patched!) correctly to contain the threat. Thus, the conservative assumption is to assume that the firewall doesn't exist. Once the perimeter curtain drops, it can be quickly shown that identity and access management infrastructure can make a large difference in both keeping the bad guys at bay and at creating value by enabling collaboration between customers, partners and the company at the center.

If the application owners assume that they're all inside a fortress, the applications typically have an anemic authentication and authorization model. At best, authentication relies on a single factor, usually a username/password combo. At worst, there's no authentication and it's either derived from the fact that you're on the internal network with your credentials lifted from the desktop or the application doesn't even bother to authenticate you. The latter is common for content-based apps (hey, wer're on Intranet, whee).

Authentication is a binary state - you're either in or you're out. Authorization, on the other hand, is a much more fluid phenomena. You can be inside the fortress walls, even inside the building because the front door was poorly locked but you won't be able to do much after that if you need 50 different keys (privileges, permissions, broadly - entitlements) to open one more door leading to treasure. The role of entitlements and their place in an authorization model suddenly becomes crucial to reflecting the attack. Deploy adaptive access control on the front-end where transactions as benign as a page retrieval or a form submittal could be considered in a real-time risk score and deploy fine-grained entitlement attestation on the back-end to catch deviations and you've got a credible defense mechanism. (If you open the gates to the world and remove the firewall, what do you do about dirty packets, be they viruses or denial of service attacks? Gartner's Neil MacDonald says you virtualize and proxy everything).

Fortifying each app is expensive so why do it? Think about the parties you do business with, typically your customers and your partners. Your large customers and most valued partners will want to participate in your business processes, be they sales, order fulfillment, distrubution or garbage collection. How do you let them into your shop? Easy solution - require them to play nice with your perimeter, e.g. require them to use VPN or secure tunnel. Harder solution - deploy an app, usually a web app (e.g. a portal) that exposes relevant chunks of a business process. Hardest solution - don't do anything, your CRM, ERP, SFA and other apps already have your business processes implemented on top of them. All you need is for the process to extend beyond the perimeter, easy and secure collaboration. Why waste money on building yet another app or reinventing the wheel by changing the current process when you can take a few important apps, make them into islands and open the gates.