The Smoking Monkey: The Trials and Tribulations of Daniel P. Raskin, Sun Identity Marketing Extraordinaire

Arrrr, me mateys!

I'm going to stand on my soap box for a few minutes to share my take on the ongoing dialogue around RBAC versus ABAC. The debate over which one is better seems to be as heated as the debate over which side of a black and white cookie tastes better (Seinfeld - Black & White Cookie Episode).

I'm constantly asked by customers about which approach I prefer. Analysts seem to enjoy this conversation as well. In fact, Kuppinger-Cole did a nice Q&A on the debate earlier this week and does a great job outlining the issues.

Critics of the RBAC model argue that RBAC is static and believe that taking an RBAC-only approach will lead to an excessive number of roles. They argue that policy decisions will need to leverage Roles plus attributes embedded within your application infrastructure.

Honestly, I think the debate here is somewhat self-created by framing it in terms of RBAC versus ABAC rather than simply acknowledging that a good policy engine needs to support both roles and dynamic attributes. It is very rare to come across customers that are able to contain all attributes within a role. I have yet to see a real-world organization with a clean RBAC implementation. Arguing for purely RBAC is a nirvana that casts a blind eye to the grey areas of the application infrastructure world.

The issue of RBAC v. ABAC is less a decision about choosing one over the other and more a decision around where one draws the line when defining roles. Todays organizations need to define a clear line between what attributes should be part of a role and what should remain application specific. The balance between how you define roles versus attributes is very use case driven and contextual to each customers environment. This boundry is often based more on business context, IT budget, perceived value of abstracting identity from apps, and a gazillion other factors that could influence what you should do.

From the perspective of entitlement enforcement, the basic jist is that any system that is going to work for a customer needs to support both ABAC and RBAC. Policy enforcement decisions need to take in to consideration role definitions and sometimes they also need to incorporate dynamic attributes from applications.

As we refine entitlement enforcement in OpenSSO (our Beta was made available in September 2009) we are looking at this from both perspectives and expecting real implementations to require a hybrid solution that is dynamic and can take in to consideration both roles and attributes. Our solution consumes roles, allows applications to push attributes to OpenSSO for policy evaluation, and allows OpenSSO to pull attributes for policy evaluation. In fact, OpenSSO also supports policy referrals or partial policy referrals to help make an "accept" or "deny" decision.

Thus, my solution is to stop arguing about RBAC versus ABAC and change the name to ARRRRRRRRR-BAC (use the best pirate voice you can muster). Thus, like the black and white cookie, we can all live together again in harmony.

The Sun Identity team will be actively participating in the Internet Identity WorkShop next week in Palo Alto. We're looking forward to talking about hot new technologies such as OAUTH and Vendor Relationship Management and hope to actively share our ideas around innovation in the identity and access management space. We just signed up as a sponsor (better late than never) and will be providing lunch on one of the days. Hope to see you there!

Below is a great webcast put on by Nick Wooler and Neil Gandhi from the Sun Identity team. They discuss all the great new things in Role Manager 5 and Directory Server Enterprise Edition 7. I'm always struck by the hypnotic power of Wooler's voice. I'm convinced he has a bright future in Books-on-Tape. Check it out!

Links for the day . . .

I just finished editing a video on how to federate to Salesforce CRM using OpenSSO in under 5 minutes. It was a lot of fun to make. Like our Google Apps Starter Kit, we'll be launching a Salesforce Starter Kit shortly that walks you through a step-by-step guide on how to do this as well. Basic jist is this solution allows you to reduce sign-ons for your employees and allows them to access Salesforce services using their enterprise credentials rather than their Salesforce credentials. Enjoy!

I wanted to update you on the news last week about Pat Patterson (aka SuperPat) moving on from Sun and our search for a new community lead.

As you all now know, Pat has moved on from Sun and thus has stepped down as the OpenSSO community lead. I want to wish Pat the best of luck in his future endeavors. He is not only an icon among the OpenSSO world, but he is also a great friend. I jokingly told Pat on his last day that he is "now dead to me," but the truth is I will miss him dearly and look forward to pestering him lots in the future.

That said, I am very happy to announce that our new OpenSSO community lead is Hubert Le Van Gong. Hubert has a long history with OpenSSO. He is an identity architect at Sun with strong expertise in IdM protocols as well as RESTful web services. He started working with OpenSSO in the context of interoperability with the Microsoft-backed web services stack. True to Sun's tradition of eating its own dog food, he then helped deploy OpenSSO and its OpenID extension as an Identity Provider for Sun employees. More recently Hubert has been working on new OpenSSO extensions like OAuth and OpenID 2.0. Check out Hubert's blog to read about OpenSSO community activity and feel free to ping him via IRC. His IRC handle is hubertlvg.

In addition to Hubert, you can always contact me directly at daniel.raskin@sun.com or Jamie Nelson, the Director of OpenSSO Engineering, at jamie.nelson@sun.com. We are also on IRC and our handles are draskin and jamiefnelson, respectively.

Please join me in welcoming Hubert to his new role and start pinging away with questions!

Our Sun identity heroine, SuperPat, recently wrote a nice blog on a new feature in OpenSSO Express 8 -- Simple Microsoft Active Directory configuration. Download Express 8 to test it out. We've removed a few steps to make using AD as an identity store reaaaaaaaaaally easy. Have fun.

It's heeeeeere!

Have you heard colleagues talking about OAuth, but don't understand how it can be used in the real world? Are you looking for lightweight solutions to federate with Java and .NET apps? Would you like to offer multi-factor authentication without having to purchase token hardware for all your employees?

Watch this FREE webinar and learn how Sun Microsystems, Inc. is innovating in these areas and many more to provide simple, pragmatic solutions in a single product. You'll learn how the latest release of OpenSSO can help you secure all your core resources with a single product regardless of whether your resources are internal, external or in the cloud.

If you have a spare hour tomorrow (Wednesday August 18th 2009) morning, join me as I will be presenting a webinar titled OpenSSO Express for Improved SSO. The webinar is at 10am PDT/1pm EDT/7pm CET for an update on the very latest features in OpenSSO Express 8 and beyond, such as mobile one-time passwords, the Fedlet for .Net, and SalesForce.com integration. We will also be previewing our OAuth Token Service.

OpenSSO is now part of the Nationwide Health Information Network (NHIN) CONNECT Architecture. CONNECT implements a flexible, open-source gateway solution that enables healthcare entities – Federal agencies or private-sector health organizations or networks – to connect their existing health information systems to the NHIN.

As part of CONNECT, OpenSSO acts as the:

1) Authentication Service for citizen registration
2) Policy Enforcement Point
3) and one of two choices for a pluggable Policy Decision Point

Read about OpenSSO and the CONNECT Reference Architecture here!

Theeeeeeeey're heeeeeeeeere . . .

Check out the preview of our new OAuth Token Service. You can now use REST and the OAuth Token Service for securing your apps. It's a nice, light-weight alternative to WS*.