The 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.

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.

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.

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.

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!

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.

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.

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.

But, 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.

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.

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: HP Sun IdM Provisioning

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.

Hey all. Sorry (again) for the lack of blogging, but busy getting ready for new versions of IdM and welcoming our Vaau friends to the good ship Sun.

One question keeps coming up over and over again and think we finally got the straight answer on why the Sun IdM LDAP v3 resource adapter (ours we suspect is based on the OpenLDAP standard) does not work with the LDAP v3 compatible ADAM interface to AD by Microsoft. Logic would make one think that it would.  Many customers would surmise that instead of buying two adapters, they could buy one LDAP adapter for directory and then reuse the same adapter to control AD via ADAM ("Gee, its LDAP v3 compliant, Microsoft tells me so"), thus saving the licensing fee on the AD adapter.

The argument always boiled down to MS claiming they were v3 compliant so our adapter must be at fault, but nobody ever answered why there was a problem technically. Think we have determined the answer:

First ADAM is the assumption that it is an LDAP interface of Active Directory that adheres to RFC3377 - an umbrella RFC containing 8 other RFC's to define the LDAP v3 protocol. This was first published in 1999 with Microsoft releasing ADAM on Windows 2003 several years later. One missing element from the RFC was a clear definition of the user objects, so extension RFC2798 was created April 2000 to define InetOrgPerson. Key feature to note here is the inclusion of a 'uid' attribute for user logon, not defined in the core RFC schema. As AD uses a form of distinguished name versus login ID, it did not concern itself with 'uid'.

Statement: at that time, around 2003, Microsoft could claim ADAM to be v3 compliant because it did not include 'uid' which was part of a RFC extension, not part of the core LDAP definition of the v3 RFC family.

When the InetOrgPerson RFC was published, ADAM and AD were already too far along in development to include them, so Microsoft put out an "InetOrgPerson" service kit that basically altered the schema of AD to make it compliant. The kit had to be applied to AD and not everyone did, because in a mostly Microsoft shop, the attributes used by InetOrgPerson were not used by AD in day to day operations.

The ADAM interface at this time would be considered LDAP v3 compliant because it handled all bind requests and responses as defined in RFC3377 and you could extend the schema with the InetOrgPerson toolkit to make the interface compliant with the extension RFC2798 to include InetOrgPerson. Interestingly, we would surmise this would have been most likely a null field, as AD has no use for 'uid' or login id.

Now skip forward to the development of the then Waveset, now Sun IdM LDAP resource adapter.  I cannot confirm this (we don't let our code out of the lab), but one would expect us to have used the OpenLDAP project as a code base (or some similar code library which would have been an offshoot of OpenLDAP) somewhere in the 2003/2004 timeframe. That code is kept up to date and included the InetOrgPerson Schema as part of the library, as they wished to be totally compliant to LDAP v3 core and all extensions.  And we would have designed the adapter to key off of the 'uid' field as one way to determine account uniqueness. It could be used in standard LDAP, but not in ADAM, which was an LDAP front for AD, which does not use it (at least I don't think it does; don't have an old Windows 2003 server lying around the cave to test).

Now, move forward to 2006, when the LDAP v3 protocol has still not been ratified, but had gone through enough changes in the RFC process they were updated and reissued.  RFC4510 replace RFC 3377 as the core umbrella RFC for the LDAP v3 standard. One of the RFC's controlled is RFC4519 LDAP v3 Schema for User Applications.  Lo and behold, the 'uid' attribute is no longer in the extension, but in the specification itself.

Statement: upon the release of the 2006 version of the protocol, ADAM would no longer be compliant. Can't be sure if that includes a site that have applied the InetOrgPerson toolkit, but the core ADAM interface, which seems not to have been updated since release in 2003.

Anyway, in order to get our future ADAM resource adapter to work, it appears a change to the AD schema is needed to add the needed fields.

The second reason for it not working is, in order to do ActiveSync on the ADAM interface, we need access to the LDAP transaction log, which is available LDAP directory, but not through ADAM (which uses AD via ASDI).  We had to do some work arounds to get the desired functionality of the resource adapter.




Technorati Tags: sun idm identity management software SunIdM IdentityCrisis

Well, its official folks. Sun has reached a definitive agreement to purchase Vaau and its RBACx product line.

One of the things analysts give Oracle credit for is "Vision", though acquiring identity software companies to cobble together a solution (have you seen all the moving parts in Oracle?) and slapping a label on it "Fusion" does not strike me as "visionary" at all.   Ask Oracle's John Wookey, who has been replaced as lead on the Fusion project "amid growing worries that the pivotal, complicated initiative may underwhelm customers and investors  when it arrives in late 2008".  Why customers buy into smoke and mirrors on mission critical software projects is way beyond me.

So why the crank on Oracle when we should be celebrating the Vaau purchase?  Won't Sun have the same problem?

The good news is no.  We have been working closely with Vaau for several years now when we recognized their advanced position in the RBAC space. Instead of trying to play catch up, thus consuming valuable IdM resources working hard on 7.X audit and reporting features, we partnered with Vaau, letting them do what they do best and we keep strengthening the core platform.

We have had a resource adapter for RBACx, the Vaau product, for well over a year now. RBACx can be fed user information that IdM knows, role mine new user roles, and feed that back into our product.  We have been learning what true RBAC is in this space and have made product plans to incorporate these features in the future, without requiring a "big bang" (wasn't that a big Fusion?) IT shops and enterprises find difficult to swallow.

So, we are not buying a software shop to plug a hole in a large amorphous cloudy vision and hope to deliver something some day, we are finally welcoming in a valued partner who we have worked with for quite some time.  This is validated by Deloitte's Security & Privacy Services, which has done its due diligence on Vaau and Sun, and has committed to delivering their Enterprise Role Lifecycle Management (ERLM) service based on this technology. This will combine provisioning IdM from Sun, Vaau's role management, and Deloitte's services to create a complete enterprise RBAC solution.  This is not a future deliverable. Call Deloitte now and you can get started.

So, welcome to the team, Vaau. Though its like you have been here all along.

 

Technorati Tags: sun, idm, vaau, acquisition, identitycrisis, RBACx

Powered by ScribeFire.

Wanted to take a side bar from the whats new to do a shout out on the news that Deloitte has acquired Iditarod Systems' Identity Business.

I work closely with both teams on Identity Manager deployments and excited to hear the news.  Both are top flight design and deployment teams with years of experience and talent.

This is definitely a case of where the total is greater than the sum of the two parts.  Congratulations to all involved. Celebrate and then get back to work!

Powered by ScribeFire.

We are all familiar with the "Forgot Password" capabilities of IdM on the End User Interface. This venerated function has been aiding struggling users reset their password through a series of security questions/procedures. Flavors of this have been around since the early Waveset days. 

But now users will find a "Forgot User ID" button next to it now.  This will help with the other half of the "I forgot" problem and it has some unique characteristics.

As an implementor, you can turn this whole feature on or off. If on (default), the user will be taken to a new user screen where they can put in a validating email address and one or more user attributes. Of course, you have complete control on what User attributes you want to collect through this screen to aid or screen the user.

Once submitted, Sun IdM will attempt to find a matching user (one only) and send a reset password message with the user ID to the indicated email address.  The results of the search are no users found (user notified invalid information), one user found (positive match - email account ID and force password reset), or more than one account returned (developer's choice on what you want to do here).  You can also create an User Correlation Rule to help sift through the possibilities.

And different "login group" can be utilized to check more than one authoritative source to try and identify the user account that matches the user logging in. For example, while UserID is used to find the user in a company LDAP directory, you may want to first quiz the email system to see if the submitted email is valid for the company domain. This might get you more user attributes to help find the exact LDAP account.

Take a good look at the search code behind the new button; it shows a fairly sophisticated searching capability.

Powered by ScribeFire.