UPDATE (Feb 2010): The product described in this post is dead. Sun Role Manager has been renamed to Oracle Identity Analytics and the end result is NOT the same as the product announced at OpenWorld. Stay tuned for more details in another blog post.
------
by Deborah Volk on Monday October 19, 2009
5 comments
Another session at Oracle OpenWorld I attended was for Oracle Identity Analytics (OIA), a new product Oracle built from existing parts for 11g. The product was first announced in early summer of 2009 but if you were reading Oracle tea leaves, you knew about it even before that.
Oracle Identity Analytics is a "classic" BI solution circa 2009 with features specific to identity and access universe sprinkled throughout. Oracle calls it a "unique, BI-centric approach" to identity and audit compliance. The ingredients of this cake are:
1) a slick BI front-end (thank you, Oracle BI suite)
2) a data warehouse (read: Oracle database optimized for reporting and analysis)
3) a way to extract and transform data from various sources for loading into OIA (thank you, Oracle Data Integrator)
4) a way to make sense of the data and discover hidden patterns (thank you, Oracle Data Mining)
5) tight(er) integration with neighbor products in the IAM suite, namely Oracle Identity Manager
Functionally OIA is a mashup of three slices: reporting, analytics and attestation. Segregation of duties is also part of OIA and it could be considered a fourth slice but let's pretend it's part of analytics. (If we wanted to be classification purists, we'd note that reporting is also an analytical feature, usually referred to as descriptive analytics. Attestation, on the other hand, doesn't fit as neatly into an analytics sandbox). A picture is worth (less than) a thousand words in the previous paragraph:
Oracle Identity Analytics is a "classic" BI solution circa 2009 with features specific to identity and access universe sprinkled throughout. Oracle calls it a "unique, BI-centric approach" to identity and audit compliance. The ingredients of this cake are:
1) a slick BI front-end (thank you, Oracle BI suite)
2) a data warehouse (read: Oracle database optimized for reporting and analysis)
3) a way to extract and transform data from various sources for loading into OIA (thank you, Oracle Data Integrator)
4) a way to make sense of the data and discover hidden patterns (thank you, Oracle Data Mining)
5) tight(er) integration with neighbor products in the IAM suite, namely Oracle Identity Manager
Functionally OIA is a mashup of three slices: reporting, analytics and attestation. Segregation of duties is also part of OIA and it could be considered a fourth slice but let's pretend it's part of analytics. (If we wanted to be classification purists, we'd note that reporting is also an analytical feature, usually referred to as descriptive analytics. Attestation, on the other hand, doesn't fit as neatly into an analytics sandbox). A picture is worth (less than) a thousand words in the previous paragraph:

Reporting, analytics and attestation deliver on challenges surfaced in Governance and Risk areas of IT. Is OIA then a GRC product? Well, it's 2/3 of one! If you consider attestation a compensating control, then one could say it's a narrowly defined GRC solution. Furthermore, OIA took over role mining and some other features of Oracle Role Manager (ORM) that were left on the floor after identity administration aspects of ORM were surgically removed and donated to Oracle Identity Manager 11g.
From the reporting perspective, OIA's raison d'etre is easy to grasp. All Oracle IAM products have reporting features yet reporting on identity or access events in a silo fashion (each product does its own thing on top of its own data store) is not the best solution. It's a good solution in that it meets the needs of many customers, especially customers who start with a particular product such as Oracle Identity Manager and may not deploy other pieces of the Oracle IAM suite. While it is true that there are single-product customers out there, it is also true that there are plenty of customers who own and deploy more than one Oracle IAM product. Comparing the number of single- vs multi-product deployments, multi-product installs win, at least this has been our experience. For customers deploying multiple Oracle IAM products the question of consolidating reports and making sense of data across products is a very real one.
Oracle acknowledged this issue in 10g by providing for an optional consolidation of reporting across IAM stack via BI Publisher. The reporting slice of Oracle Identity Analytics is a direct evolution of this need. For an enterprise-wide take on reporting, you have to have both appropriate infrastructure (e.g. star schema, ETL tools, etc) and, more importantly, data collected from various operational stores. Having properly denormalized data from everywhere is necessary but not sufficient to be useful by itself. You need domain-specific interpretation of this data. In the IAM world, this is bubbled up via two intertwined aspects: compliance / audit and risk mitigation. In plain English: stop the auditors or regulators from fining us for having poor controls that may lead to attacks/breaches OR reduce the likelyhood of attacks/breaches so that auditors and regulators will have a chance to fine us for something else.
In the analytics context, correlation across identity and access events in various silos creates the coveted synergistic effect where 1+1 = 3. As Security and Information Event Management (SIEM) vendors will tell you, successful correlation is 80% perspiration of having to come up with rules / criteria for correlation and associated alarms (is it a malicious attacker or merely a clueless user who can't remember his password, forgot his door access code and borrowed a card key from a friend) and 20% of having the data in one place. Thus, having some pre-packaged correlation reports covering Oracle IAM suite products as data sources would be nice to have.
The mention of SIEM is not entirely accidental. Oracle Data Integrator is a general-purpose ETL tool and as such it can be used to grab data from any target be it an Oracle IAM product, an Oracle application or a 3rd party app. The target doesn't even have to be a database, the data could come from flat files offloaded from a mainframe, for example. This 'digest and correlate all data' approach is reminiscent of SIEM products and someone in the audience at OpenWorld asked if Oracle is moving into SIEM territory with OIA. The answer was no or, to be more precise, the answer was "not now". OIA won't deal with data sources that have tradtionally been part of the SIEM landscape, e.g. network devices. Nevertheless, the distinction seems to be purely technical to me since OIA is clearly capable of dealing with any kind of data.
From the reporting perspective, OIA's raison d'etre is easy to grasp. All Oracle IAM products have reporting features yet reporting on identity or access events in a silo fashion (each product does its own thing on top of its own data store) is not the best solution. It's a good solution in that it meets the needs of many customers, especially customers who start with a particular product such as Oracle Identity Manager and may not deploy other pieces of the Oracle IAM suite. While it is true that there are single-product customers out there, it is also true that there are plenty of customers who own and deploy more than one Oracle IAM product. Comparing the number of single- vs multi-product deployments, multi-product installs win, at least this has been our experience. For customers deploying multiple Oracle IAM products the question of consolidating reports and making sense of data across products is a very real one.
Oracle acknowledged this issue in 10g by providing for an optional consolidation of reporting across IAM stack via BI Publisher. The reporting slice of Oracle Identity Analytics is a direct evolution of this need. For an enterprise-wide take on reporting, you have to have both appropriate infrastructure (e.g. star schema, ETL tools, etc) and, more importantly, data collected from various operational stores. Having properly denormalized data from everywhere is necessary but not sufficient to be useful by itself. You need domain-specific interpretation of this data. In the IAM world, this is bubbled up via two intertwined aspects: compliance / audit and risk mitigation. In plain English: stop the auditors or regulators from fining us for having poor controls that may lead to attacks/breaches OR reduce the likelyhood of attacks/breaches so that auditors and regulators will have a chance to fine us for something else.
In the analytics context, correlation across identity and access events in various silos creates the coveted synergistic effect where 1+1 = 3. As Security and Information Event Management (SIEM) vendors will tell you, successful correlation is 80% perspiration of having to come up with rules / criteria for correlation and associated alarms (is it a malicious attacker or merely a clueless user who can't remember his password, forgot his door access code and borrowed a card key from a friend) and 20% of having the data in one place. Thus, having some pre-packaged correlation reports covering Oracle IAM suite products as data sources would be nice to have.
The mention of SIEM is not entirely accidental. Oracle Data Integrator is a general-purpose ETL tool and as such it can be used to grab data from any target be it an Oracle IAM product, an Oracle application or a 3rd party app. The target doesn't even have to be a database, the data could come from flat files offloaded from a mainframe, for example. This 'digest and correlate all data' approach is reminiscent of SIEM products and someone in the audience at OpenWorld asked if Oracle is moving into SIEM territory with OIA. The answer was no or, to be more precise, the answer was "not now". OIA won't deal with data sources that have tradtionally been part of the SIEM landscape, e.g. network devices. Nevertheless, the distinction seems to be purely technical to me since OIA is clearly capable of dealing with any kind of data.

Attestation is the second slice of OIA and it's probably the slice that's going to be the driver for deploying this product. With attestation targets covering the entire range of possibilities - user accounts, roles, entitlements, membership sets (both role and group) - and attestation workflow appearing to be quite flexible (multi-level AND event-based with advanced support for reminders, escalations and delegation), on paper OIA meets 80% of attestation requirements out of the box. This is a shot across the bow of vendors such as Aveksa and Sailpoint as well as many other identity audit / compliance solutions that have been sold to the line of business.
It's worth noting that attestation generates actionable events, i.e. if an employee left the company but his account and associated access is still alive and well, attestation could kick-off a de-provisioning workflow. With entirely contained in Oracle Identity Manager, both reporting and action steps of attestation process were in OIM. In 11g, reporting side of attestation will be in OIA but action will remain in OIM. Oracle promises to have 2-way integration so that when someone attests in OIA, OIA will call OIM to execute an appropriate action on the target of attestation.
Segregation of Duties (SoD) is another interesting piece of OIA. OIA will have its own SoD engine which could be used to centralize an entire SoD policy lifecycle in OIA, including policy definition, preventive SoD simulation (detect conflicts at design-time), detective SoD check (detect conflicts at run-time), and mitigation. SoD checks and violations are recorded as events in OIA data store so that they could be reported on or sliced and diced along with other data. Since Oracle owns a powerful SoD capability from its acquisition of Logical Apps, the distinction between OIA SoD (aka SoD for Enterprise IT) and Logical Apps SoD (aka SoD for Oracle e-Business Suite) was carefully painted. (Another reason for this distinction is OIM 10g integration with Logical Apps).
It's worth noting that attestation generates actionable events, i.e. if an employee left the company but his account and associated access is still alive and well, attestation could kick-off a de-provisioning workflow. With entirely contained in Oracle Identity Manager, both reporting and action steps of attestation process were in OIM. In 11g, reporting side of attestation will be in OIA but action will remain in OIM. Oracle promises to have 2-way integration so that when someone attests in OIA, OIA will call OIM to execute an appropriate action on the target of attestation.
Segregation of Duties (SoD) is another interesting piece of OIA. OIA will have its own SoD engine which could be used to centralize an entire SoD policy lifecycle in OIA, including policy definition, preventive SoD simulation (detect conflicts at design-time), detective SoD check (detect conflicts at run-time), and mitigation. SoD checks and violations are recorded as events in OIA data store so that they could be reported on or sliced and diced along with other data. Since Oracle owns a powerful SoD capability from its acquisition of Logical Apps, the distinction between OIA SoD (aka SoD for Enterprise IT) and Logical Apps SoD (aka SoD for Oracle e-Business Suite) was carefully painted. (Another reason for this distinction is OIM 10g integration with Logical Apps).

If I read between lines, the SoD engine in OIA may be used by other IAM products in the Oracle stack for, well, dealing with SoD issues. If OIA contains data from many apps in the IAM suite, then SoD could be truly a killer app since (perhaps for the first time) one can truly consider toxic policies or business rules based on events that span IAM products. I suppose there's nothing to prevent any app from querying OIA's SoD engine so that OIA may eventually morph into more of a decision engine rather than just an analytics app.
Release date of OIA 11g is calendar year 2010. It will be aligned 11g releases of OIM and OAM.
Release date of OIA 11g is calendar year 2010. It will be aligned 11g releases of OIM and OAM.
by Deborah Volk on Wednesday October 14, 2009
7 comments
Hot off the Oracle OpenWorld presses, I give you OIM 11g:

To expand a bit on the above highlights:
1) Shiny new web UI based on Oracle's Application Development Framework (ADF).
2) BPEL-based request/approval workflows. By using inference and set algebra, I can claim that provisioning workflows will stay "as is" (if there can be such a state as "as is" in 11g). To see is to believe so we shall see.
3) Embedded Oracle Entitlement Server (OES) that will deliver enough semantic firepower in rules that make up various authorization pieces. I am calling this an OES microcontainer (please send me a royalty check if you use the term). This should make it easier to implement real-world business processes in OIM. The primary use case enabled by this is attribute-level delegated administration where you can say that all users with department="Engineering" and cost center="123" can do or have access to function blah in OIM.
4) The identity administration pieces of Oracle Role Manager (ORM) will move to OIM. Management of roles, their relationship to various entities and associated lifecycle will be in OIM. To help with role-based stuff, a few classification nodes in the overall OIM asset taxonomy will be introduced, namely role categories, namespaces and owners. Since roles are now part and parcel of OIM, their membership can be managed via requests and there's a bunch of role-based use cases sprinkled throughout the product.
5) New reconciliation engine. Performance was Oracle's top goal when rewriting the recon engine. This was achieved by pushing a (larger) portion of the transaction to the database via stored procedures and horizontal table partitioning. For a performance-starved and scale-hungry customer, this is a declaration of love. Only time (and millions of reconciliation events banging against the glass) will tell. (Better get some DBAs on your team now!) As a bonus, reconciliation event manager is now available on the web, no need for Operations people to use Design Console. It's been improved as well with an eye toward helping out Operations. For example, it. allows the capture of justification for manual operations such as manual/ad-hoc linking of events.
6) SPML-based web services for identity administration. This is already available in 10g. I don't know if the guts have been changed but 11g reads like an expansion of the current SPML web service interface with coverage for operations new in 11g, e.g. role admin. This was touted as an example of "Identity as a Service" with OIM acting as an authoritative source of identity info for the rest of the products in IAM stack and beyond (collective moniker: Fusion Middleware and Apps)
Some of the request workflow gaps that currently require a bit more engineering than expected by customers from an out-of-the-box-product have also been fixed. Namely, account modification requests (generically "modify requests") are now available thanks to BPEL workflow (ok, human tasks in a BPEL process). Thanks to BPEL engine being quite a bit more flexible than the current "homegrown" workflow engine in OIM, a slew of workflow features are available when dealing with requests, including dynamic routing, retraction, bulk actions, assignment to groups and more.
So the SOA/BPM and IAM worlds have finally collided. I predicted as much all the way back in April (Yes, my crystal ball is very special) If I look at my crystall ball now, I think eventually OIM may be nothing more than a specialized application running on top of a SOA/BPM platform.
Oracle Role Manager has been sent to sleep with the fishes. Its turf is going to be taken over by OIM on the identity administration side and by Oracle Identity Analytics (OIA) on the reporting/analytics side.
1) Shiny new web UI based on Oracle's Application Development Framework (ADF).
2) BPEL-based request/approval workflows. By using inference and set algebra, I can claim that provisioning workflows will stay "as is" (if there can be such a state as "as is" in 11g). To see is to believe so we shall see.
3) Embedded Oracle Entitlement Server (OES) that will deliver enough semantic firepower in rules that make up various authorization pieces. I am calling this an OES microcontainer (please send me a royalty check if you use the term). This should make it easier to implement real-world business processes in OIM. The primary use case enabled by this is attribute-level delegated administration where you can say that all users with department="Engineering" and cost center="123" can do or have access to function blah in OIM.
4) The identity administration pieces of Oracle Role Manager (ORM) will move to OIM. Management of roles, their relationship to various entities and associated lifecycle will be in OIM. To help with role-based stuff, a few classification nodes in the overall OIM asset taxonomy will be introduced, namely role categories, namespaces and owners. Since roles are now part and parcel of OIM, their membership can be managed via requests and there's a bunch of role-based use cases sprinkled throughout the product.
5) New reconciliation engine. Performance was Oracle's top goal when rewriting the recon engine. This was achieved by pushing a (larger) portion of the transaction to the database via stored procedures and horizontal table partitioning. For a performance-starved and scale-hungry customer, this is a declaration of love. Only time (and millions of reconciliation events banging against the glass) will tell. (Better get some DBAs on your team now!) As a bonus, reconciliation event manager is now available on the web, no need for Operations people to use Design Console. It's been improved as well with an eye toward helping out Operations. For example, it. allows the capture of justification for manual operations such as manual/ad-hoc linking of events.
6) SPML-based web services for identity administration. This is already available in 10g. I don't know if the guts have been changed but 11g reads like an expansion of the current SPML web service interface with coverage for operations new in 11g, e.g. role admin. This was touted as an example of "Identity as a Service" with OIM acting as an authoritative source of identity info for the rest of the products in IAM stack and beyond (collective moniker: Fusion Middleware and Apps)
Some of the request workflow gaps that currently require a bit more engineering than expected by customers from an out-of-the-box-product have also been fixed. Namely, account modification requests (generically "modify requests") are now available thanks to BPEL workflow (ok, human tasks in a BPEL process). Thanks to BPEL engine being quite a bit more flexible than the current "homegrown" workflow engine in OIM, a slew of workflow features are available when dealing with requests, including dynamic routing, retraction, bulk actions, assignment to groups and more.
So the SOA/BPM and IAM worlds have finally collided. I predicted as much all the way back in April (Yes, my crystal ball is very special) If I look at my crystall ball now, I think eventually OIM may be nothing more than a specialized application running on top of a SOA/BPM platform.
Oracle Role Manager has been sent to sleep with the fishes. Its turf is going to be taken over by OIM on the identity administration side and by Oracle Identity Analytics (OIA) on the reporting/analytics side.

It'll be interesting to see the deployment requirements. OES microcontainer is embedded but will the same be true of SOA Suite components necessary for BPEL workflows to work? I doubt it. We'll probably witness the pull-through conquest model employed by legacy Oracle Identity Management stack. OIM will drag SOA pieces along and plant the Oracle SOA Suite seeds whether you like it or not.
Connectors have been mentioned briefly as in "there will be new connectors". On the reconciliation side, backward compatibility was highlighted ("no change to existing connectors or existing reconciliation config data") but I wonder about the rest of the APIs and backward compatibility in general. I am sure there will be lots of twists and footnotes to this story as it develops.
Release date of OIM 11g is calendar year 2010, somewhere between January 1st and December 31st. Apparently all Oracle PMs have been threatened with the worst punishment imaginable - exile to Support - if they narrow it down to a time period less than a year wide.
Last but not least, I don't see any room for Sun Identity Manager or Sun Role Manager in this new world order. Perhaps certain pieces could be extracted from Sun products and dropped into OIM 11g but off the top of my head, I can't think of any. If someone knows better, please leave a comment. Although we're far from seeing the curtain rise (or fall) on the Sun/Oracle deal, when it comes to combining the identity administration products (identity and role managers), I can claim to be at least 50% correct in my Suncle forecast.
Connectors have been mentioned briefly as in "there will be new connectors". On the reconciliation side, backward compatibility was highlighted ("no change to existing connectors or existing reconciliation config data") but I wonder about the rest of the APIs and backward compatibility in general. I am sure there will be lots of twists and footnotes to this story as it develops.
Release date of OIM 11g is calendar year 2010, somewhere between January 1st and December 31st. Apparently all Oracle PMs have been threatened with the worst punishment imaginable - exile to Support - if they narrow it down to a time period less than a year wide.
Last but not least, I don't see any room for Sun Identity Manager or Sun Role Manager in this new world order. Perhaps certain pieces could be extracted from Sun products and dropped into OIM 11g but off the top of my head, I can't think of any. If someone knows better, please leave a comment. Although we're far from seeing the curtain rise (or fall) on the Sun/Oracle deal, when it comes to combining the identity administration products (identity and role managers), I can claim to be at least 50% correct in my Suncle forecast.
by Deborah Volk on Friday October 09, 2009
no comments
Come see us at the Oracle OpenWorld 2009 Unconference on Monday Oct 12th at 4pm. We will be in Moscone West on 3rd floor in Overlook II. Our talk is entitled "Everything You Wanted to Know About Managing Entitlements with Oracle Identity Manager (OIM) But Were Afraid to Ask". Following our session, we'll be hosting a cocktail reception between 5:30pm-7pm. Please RSVP if you'd like to stop by and have a drink with us.
Naturally, we think our session will be very interesting but in case you want to see what else is out there, Oracle IDM marketing folks put together a nice "cheatsheet" that collects all IDM-related OpenWorld content in one place.
Naturally, we think our session will be very interesting but in case you want to see what else is out there, Oracle IDM marketing folks put together a nice "cheatsheet" that collects all IDM-related OpenWorld content in one place.
by Deborah Volk on Thursday October 01, 2009
no comments
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.
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.
by Tom Ebner on Wednesday September 30, 2009
3 comments
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.
----
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!
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!
Search
Recent Posts
Topics
Access Management (19)
Ask Identigral (6)
Data Quality (4)
Identity Management (27)
Passlogix v-GO (3)
Sun OpenSSO (3)
Sun Role Manager (3)
Tags
11g 3rd bday JavaOne SAML academia accuracy active directory adapters administrative agilent ask identigral attestation audit bpel bpmn bpm business case cdi cloud computing connectors contextual search data masking data quality deployment dip entitlements federation gartner groups gtc guests insider threats insider threat java jca jms lifecycle limericks linux mashup mdm messaging nabaztag oaam oam oas obiee oc4j oel off-boarding ohs oid oif oim oow09 opensso operations osso ovd owsm passwords patching performance phi privileged accounts provisioning queues reconciliation risk rocks rogue accounts rsa10 semantics siem sim sjsds sod solaris suncle thermodynamics twitter virtual reality vpd webinar whitepapers