Tuesday November 13, 2007
Tuesday November 13, 2007 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
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.
Monday November 12, 2007 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!
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.
Thursday November 01, 2007 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.
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.