Thursday Jan 14, 2010

2010 The Year of Entitlements

2010 opens with the Identity Management field steaming forward and starting to wrestle with entitlements management.  This and the next few blogs will look at definitions, problem areas, and solutions emerging on the fine grain entitlements front.

[Read More]

Wednesday Dec 16, 2009

Never Use Emails As A Unique Identifier

This blog could just be the title and thats it. Nuff said.

One recurring major mistake I see over and over again is the use of email as a way to track unique user accounts.

Seems like a good idea.  When a new user is created, email is usually one of the first accounts they get provisioned. The email string is unique to the user, so why not use it as a way to identify user accounts across all systems? Its almost always a data element in the LDAP directory, so its available across the network for any user looking to authenticate a user.   Next thing you know, the ERP system uses it to track user accounts, the healthcare web site uses it, etc.

So what's the big deal?

The problem is two fold. First, by using a user's email account name, you are compromising the overall security of your domain.  Give me your business card and I already have one half of your login sequence.  Email account names are easy to guess, leaving one only to work out the password to gain access to many corporate systems.

And secondly, email account names may not be permanent.  Names change when one gets married. Users may want mail aliases to use nicknames or variations. Or even bigger (and this one hits close to home at this current time), the name of the mail domain may change.   If and when Sun gets acquired, everyone employee of Sun will most likely get a mail account in the Oracle.com domain.  Employeename@sun.com becomes employeename@oracle.com.  All audit trails become much more complex because you have to track across muliple UserID's to recreate a user's access.

So what is recommended?  An employee number, preferably greater than six digits. Most HR systems assign each employee a unique number.  The number is usually not easily known.  And its stays the same when the employee gets married or changes their name.  And it stays with the employee forever, even if they leave and then return later.  Add a few letters as well, say initials, would help insure uniqueness across all identity domains.

Thursday Dec 10, 2009

Agent Smith, SOD....

So lets start talking about current identity issues.

Good evening, MR. Anderson.The first that comes to mind is the us of Agent Smith, SOD (from the Separation of Duty Services Department).

Several months ago, there was a discussion about building "persona" on the web by my colleague Mark Dixon.  This was as the rising tide of social networking was rising.  Similar to a user account, which is prevalent inside the corporate firewall, the persona was instantiation of a user's , being across the web.  Its "what you project you are" through your online presence, represented by the intersection of your different entities on the web.

So this got my attention.  Not only are we the sum of our user accounts on emails, Blogs, Facebook, YouTube, Twitter, etc., but what we do with them. And most interesting is we can be what we choose to be.  We can be what we are in person or we can "avatar" up our image to be what we want to project. Any online gamer knows "ColBiggles" probably doesn't have any military experience.  But I can follow his progress, listen to his rants, read his prognostications and even talk directly to his disembodied voice without ever really knowing who or what is really driving the online persona.

This led me to think of Agent Smith from the Matrix movies, a rogue computer program that become sentient and keeps growing in power in the Matrix, learning and adding to his capabilities. Eventually, he becomes enemies with both the human and machine worlds.

So why bring this up in a blog about identities.  Because this idea of persona can be used to help implement one of the hardest of identity projects, Separation of Duties.  SOD policies are usually simple to dream up, but a devil to implement.

The idea is no one user should have certain combinations of attributes that allows that one user the ability to commit fraud or damage.  The classic case is the ability to create a vendor in the accounts payable system and release payments to that vendor. Else, my cousin may suddenly find himself being sent sizeable checks to his fictious company to cash and enjoy.

Okay, simple.  Set an SOD policy that says one user, regardless of how they acquired the abilities (via assignment or roles), cannot have that particular combination of entitlements or at least it is recorded as a exception for the auditors.  Its fairly simple to do if the accounts payable system is the same enterprise system that releases the checks.  But many times, SOD conflicts can occur accross systems.

The problem is trying to figure out if an enterprise has the correct SOD policies and monitoring in place.  Imagine having to monitor a major bank IT operation of 8,000 different systems, 100,000's of entitlements across those systems. First is the daunting task of thinking of all the combinations of SOD entitlements and then building in the rules/policies into the provisioning, role management, and compliance systems to test and find these rogue users.  Just standing it up the first time could be a career.  And as entitlement management becomes more prevalent, this will only grow in significance and complexity.

And then remember that identity domains in the enterprise are amorphous. They are constantly changing.  Users are  coming and going, changing jobs, and the dreaded SOD scenario of transfer between business units (often requires them to have overlapping SOD capabilities until the transition is complete).  New businesses are acquired, new systems are brought on line. Local admins add capabilities on the fly without seeing the bigger security picture Often, an SOD conflict is only discovered after the fact, after the venerability has been exploited.

And once the SOD fabric has been laid onto the identity topology of the enterprise, how do you test it.  How can you be sure your systems are working?  Most identity suites, including ours, have SOD monitoring in their compliance packages, not in their provisioning engines.  So there is a built in lag where a user can gain SOD violation status and not be detected for a cycle when the compliance review is run.

Also, testing in production is tough to do.  In staging, you can create an SOD situation for a user and test to see if the violation is flagged.  But in production, if you create a SOD test on a production system, particularly on a SOX or HIPPA controled system, it becomes an auditing event. The security and audit teams will be notified and someone will have to remediate the condition. Up go the incident levels on your dashboards and everyone gets involved.

And lastly, even if everything is up and running 100%, how do you monitor if delegated administrators are doing their job during compliance reviews?  The weakest link in any security system is the human factor.  Had a situation recently dealing with a contracting manager who ran the third party bench of contractors. In the identity system, she had 384 direct reports with access to a variety of entitlements across the enterprise.   For certification reviews, she had no idea, would do a "select all" and approve.

So how to test accross the production environment without sending up SOD violations to answer for?  This is where Agent Smith comes in.  Create a rogue user persona, a la Agent Smith,  that everyone is aware of and knows is a non-existant user of the company's systems. Actually create this user account downstream of your HR system (the company would not want to fund healthcare or stock benefits to a non-existant employee) and use that one user account to test your controls and monitoring.

As new SOD policies are enacted, try and see if your Agent Smith can attain an entitlement status that triggers the monitoring policy.  If the violation is triggered, security and auditing will realize, from seeing the Agent Smith persona as the violator, that it is a test account and will not raise an official violtion instance.

Also encourage delegated administrators to try and utilize the Agent Smith persona to improve its capabilities and entitlements.  Have them have Agent Smith request access to systems they should not to see if the human approvers are doing their job.  Anyone looing down the list of user entitlements should be able to pick out First Name: Agent, Last Name: Smith and deny them certification.

Granted Agent Smith, if properly treated as a real person, will consume real resources. They will get issued a laptop or email account, they will consume an ERP seat license, a MS Office allocation, etc.  This could run into several thousands of dollars (what you would spend on a real human), but this is a small cost compared to an SOD violation.  Well worth the investment.

And yes, you will have system admins, security, and auditing teams complaining about having a ficticious persona within their systems.  But they will have to understand that for the good of the SOD review at an enterprise level, it is the only way to be sure.

But be forewarned.  Just like the Agent Smith in the Matrix movies, it can take on a dangerous life of its own.  Most SOD policies involve powerful entitlements and a malicious person could assume the Agent Smith persona (this is different from the movies where the Agent assimilated humans) and actually commit fraud using his capabilities.  So, if you choose to unleash an Agent Smith, insure accees to that account is considered root level enterprise status.  Only a few should have access to the login and insure the password is religiously reset on at a minimum a weekly basis.  Be sure to test deactivating the good agent regularly and be ready to morph that one account at least once a year into Agent Jones or whatever to insure the good agent hasn't "gone rogue" within your enterprise systems.


Monday Dec 07, 2009

Identity Crisis is Back Online

Identity Crisis is back on line with some changes.[Read More]

Thursday Jun 19, 2008

New IdM 8.0 Data Exporter

Sun IdM Data ExporterThe new Identity Manager 8.0 data exporter is a major new feature. As mentioned before, the architecture for Identity Manager is "data sparse", meaning we mostly store meta data about users and accounts, not the actual value. This greatly reduces the chance of passing "stale data" to systems under management. When you want to know a user's email address is, Identity Manager retrieves it from the email system, not from a repository. You have the freshest data, not what you think it was the last time you sync'd up.

This model has proven to be the correct approach in provisioning design. But it comes up short when customers want to do more auditing and performance analysis. When all you have is current fresh data, its tough to ask the question "who had access to the financial system the first two week of the month when a security breach occurred?" or "how long on average does it take for a user to be provisioned?". We can do it, but it gets messy in the audit logs.

So now 8.0 has a data exporter sub-system built in. It allows the deployment team to determine what objects in IdM they want to report on and capture that data from within IdM and post it to a series of staging tables. These staging tables can then be accessed by the warehouse ETL to bring the data into the warehouse.

The process is really quite elementary. A data exporting task is started that will form the data from the underlying IdM objects. You can run the task to only bring out information that has changed from the last time the data export task was run. The data is then loaded into the staging tables. This data is then transferred into the customer's dataware house of choice.

There are two schemas that need to be used. The first is an ObjectClass schema that helps form the object data within IdM into something that matches the staging tables schema. IdM 8.0 comes with scripts to build these staging tables in all of the supported repositories. They represent most of the important objects within IdM. If you want to export extended attributes, you will have to modify these ObjectClass schemas and tables. IdM also provides export schemas to read the staging tables and help modify the data into something the warehouse beans can consume. As shown above, we also provide a way to connect to the external tables and perform basic forensic reports from within IdM.

The beauty of this staging table dual schema approach is it abstracts the underlying structure of IdM from the data export interface, allowing changes to be made to IdM in future versions and not "break" existing export configurations. It allows IdM to be changed and the warehouse to change and not require a complete reconfiguration.

The new data export feature uses Java Hibernate as the underlying transformation engine, which aids in the mapping of the IdM Java Objects into relational database table structures. IdM 8.0 provides default Warehouse Interface Code (WIC) that are Java classes that define the underlying schema of common IdM objects. Not all IdM objects are defined, but the important one are. They should work in a majority of the IdM deployments, but if extended or custom attributes need to be exported, these WIC classes will need to be redefined and regenerated. We include both binary and source versions of this code to help in the deployment configuration.

If you are considering using the data exporter feature, be sure to consider the impact it will have on the server it is deployed on. You may want to consider having a dedicated server for the exporting engine, as it is resource intensive. You definitely do not want to run it on a server that has a user GUI interface running, as this will slow the response time. You can schedule the exporter tasks to run in off hours to lower this impact. Good news, the new data exporter subsystem has JMX interfaces on both the pre and post staging tables beans to allow performance monitoring on how fast the exporter is working.

More in future posts. For now, good documentation is available from our public website.

Tuesday Jun 17, 2008

Whats not new in Sun Identity Manager 8.0

Big week this week with the release of Sun Identity Manager 8.0. Many of our partners are already trained and working with the new version. Plans are already being discussed on upgrades to client sites to the new IdM 8.0 to take advantage of roles and the data exporter.

Before we get into more of the details of the new features, wanted to get off a quick entry on what features are no longer available or not supported yet. Knowing what is and is not in the product is important.

So, without further ado. Here is what is not in Identity Manager 8.0:

1) Java based Business Process Editor (BPE) - originally shipped with Waveset products and enhanced over the years. In 6.0, we started to migrate the configuration capabilities into a Netbeans plug in. Each new release improved on the integration with Netbeans (meaning, originally, the plug acted like the BPE, but now it is more aware of the features and capabilities of the Netbeans platform). So as of IdM 8.0, all BPE type work will be done through the Netbeans plug in. Thus, the old BPE is deprecated and going the way of the dodo. Good news though, Sun has open sourced these plugins for all to participate in. Again, who else in this business does that.

2) Meta View - This was a good idea that never really took hold. Meta Views allowed abstracting the attributes so they can be centrally managed. Workflows and views could reference the Meta View attribute and it could be managed in one location. However, Meta Views worked great when starting out, but were order sensitive and got tricky to implement. Never really caught on. IdM 8.0 will still support Meta View upgrades, but they are deprecated and should be replaced. So to both of you who implemented them (sorry, trying to make gallows humor) should be aware the are on the way out.

3) MySQL in Production - Still not there yet. This is filed under the category real soon now. As many know, we permit MySQL in development, but do not support it in production environments. MySQL 5.1 has a known bug in parsing nested selects, which unfortunately, we use within IdM. The query will run, but the parsing engine does not always take advantage of the available indexes, so performance will suffer as the system scales, as is possible in production.

But don't we own MySQL? Isn't it fixable? Yes it has been fixed in MySQL 5.2, which never got to general release mode, and in MySQL 6.0, which is in pre-release test mode. No effort was made to fix it in 5.1. Since neither 5.2 or 6.0 is officially released, we cannot support it in production environments. Yet. Unfortunately, the code freeze for IdM 8.0 occurred before our acquisition of MySQL, so we will have to wait for the official support in a future release of IdM. Trust me, this is a priority. Real soon now.

We have also discontinued support for many older versions of software (really, who is seriously still working with Red Hat Server 2.1). Check here for a complete list of deprecated software support.



Monday Jun 16, 2008

Released: Identity Manager 8.0


Was told to hang on until the press releases went out, but here it is on the public website: Sun's industry leading Identity Manager 8.0 has been released. You can read about it here, you can download it here (yes, download. Can you do that with Oracle or IBM?), and you can read all the documentation you want from here.

So, what's new.

Roles, thats what.

And Data Exporting.

And additional resources supported.

Will be blogging about these features and other information from the release notes in the coming weeks. Don't want this to become a marketing shout out blog, because the intended purpose of this is to discuss identity projects and problems, not product features. But sometimes these new features help with the delivery of identity projects.

So what's new in 8.0 and why is it important to me? First off is role management. Identity Manager had the concept of a role in it, but at a basic level. An administrator could group a series of entitlements together and give it a role name. Then the role could be assigned to a organization node and thus have some owner be responsible for it.

But it was never really a solid role management approach. Our engineers have worked long under the hood to create a more generic object type and give roles a life (think Dr. Frankenstien "its al-i-v-e"). Roles now behave like UserObjects - they are created, they are approved, they have an owner, they can be modified, they can be audited, they can be scheduled, and they can be deactivated.

Identity Manager 8.0 has also define two types of roles - the traditional IT role, where the role gives entitlements on specific resources (this is the traditional IdM role) and business roles, which are roles that are aggregations of IT roles. They have no entitlements, but help business users better understand what a group of entitlements does.

Quick example: The role of employee identifies me as a employee, but does not really tell the world what I can do as an employee. But the "employee" role could have the IT roles of email user, phone account holder, and medical insurance account. Each of these "IT" roles have specific entitlements that give the user capabilities. They can even change based on other criteria, such as location. An employee in England or Taiwan is still an employee, but will have different IT roles compatible with their local systems.

One way to think of it is an egg carton analogy. IT roles are gathered together into a business role (an egg) and the user account is an egg carton, collecting eggs. An employee account might include "employee", "Sales Manager", "Equity owner", and "Project X Lead", each of which a non-technical business person can understand in plain language. You then peel back the business roles to get to the underlying IT capabilities through the business roles.

More on this going forward. But quick side bar; why did we buy Vaau? Is this role management from that acquisition? The answer is no; the acquisition of Vaau was completed after IdM 8.0's code was frozen for release. The two still are integrated via SPML and can work together as well as stand alone. The new Sun Role Manager (formerly RBACx from Vaau) will remain the tool of choice for full role architecture and management. But the new role management capabilities of IdM 8.0 may be sufficient for your project.

The other big new feature is the data exporter. One key feature of Sun IdM architecture is the data sparse "meta" nature of our user account repository. We don't carry all the data in the underlying database, which greatly simplifies account management because you don't have to worry about synchronicity across accounts (which of three locations has the right user email string?).

However, this data sparse model limited the ability of the repository to help in historical auditing and data analysis. Without data, you can't really do any data analysis.

So, we have a new capability within IdM. You can now "snapshot" data while it is in flight to an exporting queue. Then an exporting task is executed to push the data into an external table or bean. From there, you can massage the data to your hearts content and IdM's repository is not cluttered with vast quantities of data. We have even included a simple forensic reporter that can connect to this data and query it for answers. More on this later.

So, go download and start reviewing. We will bring more information in the coming weeks and go over the new features in detail.

Tuesday Jun 10, 2008

Ssssh. You will click if you know whats good for you.

Never can tell in a large organization who is driving the bus.

One group tells me we have to be patient and not blog about the new Identity Manager 8.0.

We want to make an announcement soon about the new Identity Manager 8.0 in a couple of weeks (PR new releases and the like). Keep it all hush hush.

So, I don't know. I guess I will have to remain silent about the new Identity Manager 8.0 until it is available on a public web site.

Til then, stay busy.

Wednesday Jun 04, 2008

Live from The Identity Road Show - Identity becoming Core Security Focus

Getting towards the end of the morning presentations of the identity roadshow.

I see a recurring theme through many of the presentations, which usually means you should put this on the emerging concern radar to keep an eye on it. The presenters are analysts, partners, and Sun thought leaders in this area. These are not wild rants in the wilderness. But I am not sure they see the common thread.

What divine from several presentation is the future of identity is to be viewed as a core competency for Security and Risk Management. Identity Management has always been positioned as an area of interest to help in the general overall Security and Risk Management strategy of a company. Many of our large SI partners have their identity practice within their Security and Risk Management practice.

However, what I am thinking I am hearing now is that instead of being a supporting pillar in the overall solution, identity management is become a core competency required to have a successful program. This is significant. No longer is identity management a nice-to-have in an overall Security and Risk Management program (oh wait, isn't the buzz word GRC (Governance, Risk, and Compliance) fit here? More on that in a future entry.) but a required feature of to a successful program.

What does this mean? A enterprise must have a real and solid approach to identity management built into their overall Security and Risk Management model/program. in order to have a viable Security and Risk Management program, a solid Identity Management strategy is strategic to success. Perhaps we should call it Security, Identity, and Risk Management?

Finally, after years of believing this and evangelizing the importance of a rock solid identity management program, we are finally getting a seat at the big table. We are no longer optional, but mandatory.

So as you slog away into the night trying to implement a new branch in a workflow or control an new set of attributes in a newly assigned resource, have heart. You toil not on the fringes, but on a project that is becoming a recognized must have within your organization. More and more what you work on will have more and more respect going forward. The knowledge you gain today will become key fundamentals in future directions of your organization.

Congratulations. But get that change done today. Your day will come. The blip is on the radar.


On another topic (teaser) - Mark down June 19th - Good things come to those who wait!

Identity Road Show Today in NYC

Usually not one who likes to read blogs and wade through "what I am doing now" entries (please, my life is fairly mundane, no need to bore the world with it), but just wanted to put in a quick note.

On the bus now (horrible hour of 6:30 AM) to join the Sun Identity Roadshow in our New York City offices. Lots of customers, partners, and Sun Identity folks. Heading in early for a "NYC power breakfast (I'm still stuck in the 80's) with Mark Dixon. He is one of our troupers and is speaking at all of the roadshows. Catch him if you can.

So how far have we come with technology? Here is my nugget for the morning. Surprisingly, Mark's contact information was a little dated on my laptop here on the bus, so I VPN'd into Sun's directory and downloaded his contact info in a VCF file. Then I remembered Thunderbird does not have the ability to bring that into my contact database (shame on Thunderbird - for open source, open formats should be a given. Great product, but missed an easy feature).

However, a little Googling on the net turns up an extension that give Thunderbird that capability. And I am downloading it from Germany. On a moving bus. Going through the Lincoln tunnel. Under the Hudson River and getting nearly 1 mbps). Like how cool is that. Oh, and it works. Will blog later on the road show.

Friday May 30, 2008

Roles versus Rules

Visited a great Sun partner to get them up to speed on some of our new releases (Identity Manager 8.0, etc.) and some of the great technology in Sun Role Manager, the former RBACx from our Vaau acquisition. Had a really good question from one of the participants - "So just what is a role and how does it differ from a rule?". It was followed up by "how many roles are just right for an organization"?

Both are excellent questions and I am not sure I am the definitive soothsayer on these answers. But, as I say, information is worth what you pay for it (and you are reading this public blog, so you've just set the value of it).

Rules vs. roles comes up often. As the identity management space continues to mature, this question is being asked more and more. Over the years, most access control has been done via rules. Only recently have roles been a viable alternative (heres a good discussion dated from 2003). Many role based projects have ended up in the weeds when it is found how difficult it is to try and wrestle all of the roles/entitlements/people into an organized logical process. Rules begat more rules.

As the old joke goes, there are two types of two types of people in the world. Those who think there are two kinds of people in the world and those who do not. A kind of Zen joke, but it really points out the problems with rules and roles.

Its gotten to the point that one of our competitors (as pointed out by our partner) is espousing you don't need roles, its just rules. Roles are just nebulous embodiments of rules, therefore not really roles. Kinda of a Koan if I ever heard of one.

So here is my take; roles are real and they contain one or more rules that help to dynamically define them. But roles can also have attributes of their own that are inherited by the assigning of a role. And they can have other roles in them.

Yes, lets clarify. I can build rules to help define access. "If a user has job code = 42, then assign them read/write access to the shipping system". There you have a basic rule that clearly assigns user access. If it helps you define a shipping employee (who always works with that job code), you could say the rule defines the role "shipping employee". Thus the rule and the role are one (have we reached "role nirvana"? Ooohhhmmm).

So thus one could say the rule is the role and thus who really needs roles? Just call it the "shipping employee rule" and everyone gets properly assigned with no roles.

But that is a base use case and if we extend it, we can prove the existence of roles. First, roles can have other rules (AND clause) so a role could be defined as a collection of one or more rules. This has the benefit of abstracting the complexity of the rules (if you have ever written complex joins in SQL, you know where I am coming from). Its easier to say "assign the role of loading dock manager if the employee is a shipping employee determined by the rule, is certified to drive a forklift (check for certification), and has the role of shipping clerk" than it is to go on and write out the gory rules. I get more detailed information from a rules only approach, but quickly get lost as things get more complex. Roles are easier to manage and, more importantly, for non involved users to understand. This means my business teams will understand the role more than a complex set of rules.

The other difference is roles can have attributes of their own that get inherited by the assignment. I may test your user status and qualify you by rules to have a role, but once you qualify for the role, you can get additional assignments. For example, using the above, if you do get assigned as a a forklift operator you get a hardhat and safety glasses. And if you also qualify as the loading dock manager, you also get a bullhorn as well. Additional assignments that are not based on rules, but by qualifying for a roles through rules. Make sense?

Thus, its not rules versus roles, but rules and roles working together.

As to the last point then, how many roles are enough? I can keep decomposing the organization into smaller and smaller roles until roles start to get out of hand (role explosion). So what is the right number? The answer is its up to the customer/enterprise. Its what they feel comfortable with. Credit card companies may be absolutely fine with 100M's credit card users that are separated solely into Green, Blue, Gold, Platinum, and Black card holders. Or they may want to get more granular.

But instead of leaving you with a circular answer again, lets just say I have heard more than one role engineering expert say that as a rule of thumb (I love rules of thumb) if you are getting more that 30% the number of roles versus number of users, you are getting role explosion and you need to drop back ten and punt. That means if you have 10,000 users, if you start designing your 3,000th role, you are probably in trouble and need to rethink your approach. Koyaanisquatsi.

Ideally, you want the fewest roles as possible that meet the needs of the business. Not too many, not too few. Its an iterative process, defining roles and rules, combining old ones, discovering new ones. It will never end. Its a long road to "role Nirvana".

Ooohhmmmmm.

Monday May 12, 2008

You Can Be An Identity Hero

Hey, all.

Been busy getting up to speed on the upcoming Identity Manager 8.0 release and getting our ducks in line with Sun Role Manager (the rebranded RBACx from the Vaau purchase). More on this later as we get closer to general release.

www.sun.com/identityBut, time for some fun. All work and no play makes Jack a dull boy.

As you know, this blog (IdentityCrisis) targets those of us out in the trenches working long hours, trying to make the clients happy and hit those deadlines. Time for a little fun.

Marketing sent out a plea for some viral blogging about a new online game they created to help make everyone more aware of Sun's Identity Software Products.

Say again?

A game about identity software packages? Must be lame. But lets check it out anyway.

Now I am not a big online gamer (Halo, all three on legendary, does makes me a legend for my 16 year old's friends) and the thought of an online game pushing software just made me roll my eyes skyward.

But I thought I would see how lame it would be.

Half hour later I was still playing it. They actually did it. I am not on the leaderboard yet, but practice makes perfect. So if you want to take a break and give it a try, go to
http://sun.com/identityhero

The Sarbox dragons give me the most trouble.

Here's the blog from marketing showing more screen shots.

http://blogs.sun.com/idmbuzz/entry/identity_hero


Take a break and go have some fun. Congratulations marketing, well done.


Tuesday Mar 04, 2008

HP Dropping Identity - Burton Group

After months of spotty blogging, two posts in one day. You lucky monkeys!

Follow up on Burton Group report of HP stalling their investment in IdM - HP's Identity Retrenchment

So you don't have to buy the whole report, but you should still.

Anyway, as mentioned before, this blog is called Identity Crisis. This is an example of why I call it that.

Today's winners are the HP customers who now have to live with the idea the software they invested in will not be "end-of-lifed" but no new sales or products will be added to the mix. Only investments will be to keep the current customer base happy. Yep, we all know how that goes.

If their IdM products were senior managers, this is the equivalent to being replaced and put on a "special project" (usually followed by a resignation to spend more time with the family).

Ouch.  

Doubt you loyal HP customers will sleep well these next few nights.  We actually do feel for you and hope to help.

While not trying to appear to be an ambulance chaser, would like to extend an invitation to those sleepy HP customers to look into our complete Identity Management stack.  We have partners and professional services to help get you to a safer place.

HP is Withdrawing from Identity Management

Seems the word is quietly leaking out. From the analysts and European bloggers.

HP has cut the oxygen off from their Identity Management Team. And, ergo, those loyal customers who bought into their half hearted Identity effort. I am a veteran of HP's investment in BroadVision at the turn of the century, so I know their pain.

This has also been confirmed with the Burton Group Analysts in their recent report:  "Provisioning Market 2008: Survival of the Fittest". Guess HP was not one.  I would reprint the snippet here, but its their IP and you should go read the whole thing. Excellent work. You will need Client access to get the report.

There is also mention on the V
ölcker Infomatik website:


HP surprisingly withdraws from Identity Management

HP withdraws from Identity Management business. For analysts this step is surprising because this segment is considered as profitable and promising. "With HP's withdrawal from this segment gives a clear signal" sais Peter Weierich, spokesman at Völcker Informatik.

At the HP Identity website, they are still pitching their capabilities for Identity. Does it bother anyone that a company would choke off its identity software, but keep pitching it in public on their website?  SO, for anyone considering an HP Identity solution, hope your company kept up its Burton subscription running.

So, to all of you HP customers, you now know why I call this blog "Identity Crisis". It war out here and the next wave is just beginning. Give us a call. We can help (see above Burton report as well).


Technorati Tags:

Monday Mar 03, 2008

Identity Manager and MySQL

So, welcome to the MySQL team; there is a tidal wave of blogs and stories, so won't go into 4-part harmony analysis what it means (its a good thing, just as everyone says). But I  did want to add about what it means for Sun Identity manager and the use of MySQL as the repository. 

Sun IdM 7.X has supported MySQL as a repository for development environments only. Now that we own MySQL, how will that change?

Well, the short answer is, in the near term, no change in position.  The problem occurs when scaling MySQL to large scale deployments. Over 8 CPUs, MySQL has thread contention problems and the scaling drops off.  As IdM uses a blobby, object oriented type database, with quite a bit of system information kept in XML snippets, our developers were noticing some problems when they tried to stress the database.  And at the time (close to a year ago), Sun did not have a formal support agreement with MySQL, so they would not give it the thumbs up to put in production. Development would be supported by Sun, but production support would be withheld until we could be sure we could get solid support from the MySQL team to possibly address customer problems.

Well, that was then and this is now.  We bought MySQL just so we could help them solve this type of support problem that has been keeping many large customers from large scale deployments in production. Now, we will own the support problems(lucky us ;-) ).

So I am confident we will solve this problem and certify MySQL across the board for IdM. But the ink is still drying on the acquisition  agreement. Give us some time to weld the technical and support teams together.  Until then, even though MySQL is now a Sun product, we will leave things the way they are (development support only) until we get things up and supported.
About

Sean ONeill

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today