This week we announced that PayPal has chosen Axiomatics XACML-based authorization – you can see the press release here.
At Axiomatics we are thrilled to have won a contract with an innovative company like PayPal and look forward to making the project very successful.
One of the points I made during my vendor lightning round session at Burton Catalyst last week was that the industry should be looking ahead to an XACML 3.0 interop in 2011, perhaps at the next Catalyst conference. Catalyst was the site of the first ever XACML interop demonstration back in 2007 and would be a great venue again next year. It is expected that more vendors will adopt version 3.0 once OASIS completes formal standardization (currently a committee draft and will shortly be voted on as committee standard).
There are some basic usage scenarios that can be tested, such as implementing policies authored in one vendors PAP in another vendor’s PDP. Another scenario that is frequently mentioned is integrating a PDP with other vendor’s PEPs. What scenarios are most important to you?
Another item to consider is whether the industry needs certified conformance testing of XACML products. This capability has been very valuable to the federation market, but there is a lot of ambiguity today for externalized authorization manager products. If vendor products were certified as conformant by independent party, would that be valuable to you?
Finally, interoperability and standards conformance are more important than ever for the externalized authorization manager market. Demand is increasing from enterprises, SaaS vendors, cloud service providers, and others. These prospective implementers of XACML-based solutions must be confident of the functionality supported in commercial products and they should have a clear understanding of interoperability capabilities. That is why we are calling on other XACML vendors to join us in planning for the next interop event and also to seriously consider sponsoring a certification process.
image credit: http://instigate.co.uk/InstigateCop.jpg
Last week marked my first visit to a Catalyst conference since departing from Burton Group earlier this year. Let’s just say it is a LOT more relaxing to be there as an attendee and speaker than as part of the production team!!
I found the latest Catalyst to be informative, entertaining, and it exuded a high level of energy – just what you want in a conference. In the identity management sessions, I appreciated the focus on externalized authorization, virtual directories, and federation. The Concordia workshop on authorization was well attended and showcased progress made in a number of areas in the recent past. The workshop also highlighted some areas where the industry can focus energy, such as:
Burton Group has a great formula for the Catalyst Conference and apparently Gartner agrees since Catalyst 2011 in San Diego was announced last Thursday. I plan to be there, how about you?
In a previous post discussing XACML performance myth-busting, I described several areas in an XACML authorization system where performance issues can be addressed. Since then, my colleague David Brossard created the diagram below to illustrate potential performance bottlenecks.
To refresh your memory, here is the issue for each numbered item in the diagram (see the previous post for explanations):
With this post, the long tail of commentary from the European Identity Conference continues. I came up with the term Anywhere Application Architecture while preparing my EIC keynote as it captures a number of principles that architects must consider when deploying applications. Today, applications and the supporting infrastructure must be able to run anywhere – and be mobile enough to transit between on premises data centers, private clouds, and public clouds. Below is a graphic that represents this approach, from an authorization perspective.
Here’s how it works: A typical authorization service is depicted in the lower part of the graphic; it is comprised of a policy enforcement point (PAP) policy decision point (PDP) and policy enforcement points (PEP). In addition, authorization policies represent the business and security rules to be enforced and necessary attributes are retrieved through a policy information point (PIP) interface.
The traditional deployment of an authorization infrastructure is to install it on premises alongside applications in your enterprise’s data center. A PEP would be typically integrated with your application (App A in this case). If your enterprise utilizes a private cloud hosting a web services application, then XML gateways can serve as a super PEP to secure access to web services (in this case Service A).
If you are running workloads in the public cloud, the same authorization infrastructure can be extended. In our example, the XML gateway can protect publicly hosted web services (Service B) or you can choose to implement a PEP in the cloud (Service C). Finally, you may also choose to run part or all of your authorization infrastructure in the cloud – depending on the usage scenarios or requirements of your applications and users.
To reiterate, security architects and application planners must prepare for workloads that can run in the data center, in private clouds or in public cloud scenarios – and they must be able to accommodate moving workloads between these environments. Therefore, your IdM infrastructure must have the same flexibility characteristics. In this example, we’ve shown you how an XACML-based authorization system fits the bill. By the way, this approach integrates extremely well with a federated model as the authentication approach. Then you can also accommodate users that are located anywhere!
The title of this post was the security pass phrase question I chose when registering for online access to a financial services firm. I called aforementioned financial services firm today and when prompted for the answer by the customer service representative, I responded “because you can’t remember the questions or answers.” Unfortunately, that was not the correct response to this knowledge based authentication (KBA) question. However, this experience is another example of why static KBA systems are a bad idea – usability. I registered for access so long ago that I can’t remember the response (I usually include them in my password safe, but did not in this instance). Being an identity-privacy zealot, I did not enter one of the usual KBA questions like, what was the first car you owned or where did I go to high school.
Why are static KBA systems still in use? They are a very weak link in the security chain, but used by so many web sites including, supposedly, security conscious banking sites. In the age of Google and Facebook, the list of good KBA questions is effectively zero. I will be happy when my account is closed with this financial institution!
What is the real risk of choosing a small, innovative vendor for your critical IT projects? On the one hand, you can purchase a product built by a vendor that specializes in a specific functional area, is passionate about customer success, and adjusts priorities to meet your particular business requirements. On the other hand, you can choose to purchase an average product, built by a vendor that has a product list bigger than the national debt, is passionate about their profitability, and pressures customers to buy into a grand vision.
What choice do you make? Which option will ensure the success of your business objectives?
