UMA is now the adjacent possible… how to position it for Ent

1. UMA is now the adjacent possible… how to position it for Enterprise adoption! At the RSA Security conference, I was lucky to hear Eve Maler present UMA to a group of enterprise API security experts. I’m offering a critique of her message with the hopes of opening up a discussion on the “marketing” of the standard within the UMA community. UMA defines a number of entities: client, resource server, authorization server, resource owner, and requesting party. If you have have only a few minutes to devote to UMA as part of a larger talk about application security, inevitably you need to highlight just one aspect of the technology. This would entice the listener to dive deeper into UMA, and its other capabilities. In the presentation, Eve stressed how people can use UMA to achieve better control of their resources. Certainly this is unprecedented with previous access management technologies. However, in presenting this advanced use case, without explaining a more basic use case, the listener may have a hard time connecting the dots on how to actually put UMA to use.

2. I think the poster child for UMA should be trust elevation, or stepped up authentication. This is critical for the Ubuntu Juju security design, and it’s not possible with OpenID Connect or SAML alone — authorization policies are needed. Furthermore there is a Trust Elevation Technical Committee at OASIS — it shows that a number of banks and other large organizations are looking for guidance on this topic. When Edison marketed electricity, he focused on how much safer it would be for street lamps if they did not use gas. In reality, the applications for electricity were beyond what Edison (or even Tesla…) ever imagined. But from a marketing perspective, his market breach plan was a brilliant success. Once UMA proves its worth for trust elevation, we will be well positioned to enable developers to use UMA in some exciting, and unforeseen ways. Here are some other suggestions that may resonate with enterprise customers who already have some kind of Web access management infrastructure in place: Stress the Authorization Server – Resource Server – Client interaction. This is familiar ground for any organizations who have implemented tools like CA Site Minder, Oracle Access Manager, RSA Clear trust, Forge Rock Open AM and IBM Tivoli Access Manager… the leading enterprise Web Access Management (WAM) platforms.

3. In fact, by stressing that UMA builds on previous generations of WAM technologies, and in some cases standardizes (using OAuth2) what had been proprietary protocols, it will give organizations an understanding of why UMA was a natural evolution of centralized access management. Talk more about what kind of policies can be expressed. A common confusion about UMA is that it is competitive with XACML. In fact, UMA is neutral on how the policy is expressed. An UMA server could certainly support XACML as the mechanism to express the policy. Centralized authorization is all about the ability to express policies about who can access what resources under what conditions, including the Resource Owner–so this may be a good place to introduce this new capability. Talk about opportunities for multiple Authorization Servers. Access Management is increasingly an inter-domain problem. In older WAM architectures, there could only be one policy server. This does not reflect the current complexity where parent and partner organizations have their own business policy requirements. Article resource-http://thegluuserver.wordpress.com/2014/05/16/how-to-benchmark-ox-for-a-large-scale-deployment/