At Sun we know that some of our competitors have a sizeable footprint in the traditional web access management space. When I say traditional, I’m referring to web access management solutions designed to support SSO and AuthZ for internal web applications. These solutions tend to be aimed at deployments of 100,000 users or less.
One trend we are seeing is that these old solutions are no longer suitable for many organizations and we are regularly being approached as a fresh alternative to replace these existing solutions and to provide additional federation services. This is due to a number of reasons including:

• The existing solution does not scale for the extranet
• The existing solution has never been successfully deployed across an organization
• The existing solution does not support federation standards or requires a major upgrade to do so

As a result, we are coming across many deal opportunities where we are being asked to replace a proprietary web access management solution over time. That is, the organization wants to move to Sun, but they don’t want to completely rip and replace their existing solution due to the fact that they have many agents deployed and do not have the budget or time to replace them all in one fell swoop. In short, when they choose to migrate to Sun’s Federated Access Manager (FAM), or OpenSSO (FAM is derived from OpenSSO), they require that the old solution be able to coexist with Sun’s solution over a period of time.
The beauty of Sun’s solution to this problem is that we can easily co-exist with the 3rd party solution (we’ve been doing this for years) and federate enable them with a single solution and a single deployment. Since we’re the only self-contained java application that does web access management and federation in a single distribution, we are unique in that you can deploy a single .WAR file to address both problems.
Easy to deply. Easy to configure. Robust in its access and federation capabilities.
Even better, FAM’s multi-protocol hub can translate federation protocols, such as SAML, WS-FED and ID-FF, and proprietary tokens, such as Oracle, Siteminder and IBM tokens, to create a single “circle of trust” between an IDP and it’s partners regardless of what protocols they are using. In short, an organization can migrate to FAM through a pragmatic co-existence strategy and simultaneously federate enable the old and new solution using a single deployment of FAM to solve both problems.
How ’bout ‘dem apples!

In many of my blogs I’ve written about Virtual Federation Proxy (VFP)a feature available in OpenSSO, the code base from which Sun’s upcoming release Federated Access Manager 8 is derived. I’ve received lots of email from people asking me to explain the benefit of this feature in more detail so this blog focuses on explaining the problem that organizations are facing and how VFP can lower the overall total cost of ownership for web access management and federation infrastructure.

THE PROBLEM
Most organizations are still working toward internal single sign-on. That is, the majority of organizations still have multiple authentication points or reduced sign on (RSO). For example, an organization may still have separate sign-ons for it’s Web Portal, HR System and Payroll system. It could be using Enterprise Single Sign On to simulate a SSO experience, but it still maintains three different authentication infrastructures. If that organization wants to begin federating with external service providers using all three applications it needs to deploy a federation service at each authentication point. In other words, an organization would need to deploy separate federation points for each applications — Web Portal, HR system and Payroll system. 

---

The problem with this is an organization needs to maintain more federation instances and infrastructure than it wants and would not be following federation best practices by implementing a single, centralized federation hub. In short, the ratio between an organizations authentication points to federation points would be a 1:1 ratio. That is, for every authentication point an organization maintains it would also need to deploy an additional federation point. This, oftentimes, is an inhibitor to beginning federation because many organizations believe they need to solve their internal single sign on issues before starting with federation.
THE SOLUTION: VIRTUAL FEDERATION PROXY (VFP)
VPN allows a company to lower infrastructure costs by reducing the # of federation instances, hardware, and ongoing support/maintenance costs required to support each individual authentication point. VFP changes the ratio of authentication points to federation points from a 1:1 ratio to an X:1 ratio. For example, the organization mentioned above that has 3 authentication points (Web Portal, HR System, Payroll System) would now only require one federation deployment to manage all 3 authentication points, a 67% reduction in hardware, software, and ongoing maintenance. In short, OpenSSO’s Virtual Federation Proxy (VFP) solves this problem by unhinging any dependencies between internal SSO and federated SSO.

---

---

VPN does this by allowing organizations to add a plug-in to each authentication point that allows it to push federation data to OpenSSO when a user logs in. OpenSSO caches the federation data and then acts as a virtual proxy on behalf of each authentication point. For example, the company mentioned above that has three authentication points would deploy a basic plug-in to federate enable its Web Portal, HR System, and Payroll System. If a user logged in to the HR system and then tried to access a partner service during the authenticated session, for example an outsourced 401K service, OpenSSO would act as a proxy for the HR application and handle all communications with the 401K service using the cached data. Once the session is terminated the cached data is deleted from OpenSSO.
Finally, as an organization makes progress toward SSO they do not need to worry about constructing, maintaining and end-of-lifing multiple federation services. Instead, it can simply change how each application interacts with a single federation hub. In short, VFP allows organizations to architect a long-term federation solution that follows best practices, simplifies their path to federated single sign on, lowers total cost of ownership, and simplifies an organizations identity infrastructure in a pragmatic manner.
Peace out!

OK Identity Competitors!
We had our video battle warm-up with the scrappy Ping Identity a few months ago, but now we challenge you to a little game called IDENTITY HERO!”
My teammates at Sun believe that they can rescue more identity enterprises than our competitors. Let’s throw down and see who can claim the highest score!!!
BOOOYAH!!!

My goal in life, besides world peace, is to make federation so simple my 15 month child, Taro, can do it. Now that’s a lofty goal, but we’re making progress towards that in Federated Access Manager 8. To give you a preview, I’ve prepared a screencast that shows the following:
* Configuring an Identity Provider (IDP)
* Configuring an Service Provider (SP)
* Creating a Circle of Trust between the IDP and SP
* Validating the federated connection
The goal is to give you an idea of how simple federation has become. Keep in mind, I’m marketing and I can do it. I’m also not one of those converts from engineering to marketing (light-side to dark-side), but rather come from a business background and have a BA in Public Affairs. In short, this stuff is not designed for identity experts, but rather dimwits like myself.
As always you can check all of this out for yourself at www.opensso.org. Enjoy the demo . . .