Archive for the ‘Uncategorized’ category

Beyond RBAC and towards ABAC – Tales from Down Under, Part 2

December 3, 2014

Welcome back! Here is Part 2 of the Axiomatics road trip to Australia and New Zealand. As mentioned in Part 1, the trip was loaded with interesting conversations and here are five more topics that warranted some additional commentary:

Business Analysts are the optimal policy authors

“Who writes the policies” is often a question we are asked by customers who are new to the ABAC approach. Every organization is different, but generally the answer is a combination of people who are familiar with the technology or who represent the business/application areas. I believe similar collaborations occur when implementing other IAM technologies, such as user provisioning or user authentication. In ABAC systems, the access rules are typically very specific to the line of business applications that are integrated. Therefore, the person writing the access rules must be very aware of the business, security, risk, legal, or privacy constraints for that particular application or business unit – IT personnel normally don’t fit this archetype. Rather, a business representative provides important input or, ideally, a person with business analyst skills should be able to complete the bulk of the policy authoring task.

Legacy security models for database content

Axiomatics recently introduced a product to filter database content, based on centrally defined and managed access policies. During the course of describing this new product, we learn about the current practices for protecting database content. It turns out that organizations have a bevy of techniques and workarounds that are somewhat analogous to the RBAC and group models used elsewhere in the organization. These techniques include stored procedures (most prevalent), customized table views, web services that call specific stored procedures, application specific code that call specific stored procedures, and others. More recently, we even heard of a customer that has a dedicated group that performs custom data extractions and manually redacts or masks data.

The above techniques suffer from some of the same limitations associated with legacy RBAC approaches. Namely, they are costly to construct and maintain, are user centric rather than resource centric and, more importantly, don’t provide the flexibility or granularity of access required in modern data sharing and collaboration scenarios.

Pre-masking data

It was very interesting to learn of one scenario where an enterprise customer preloaded a customer database with masked data in one column – and the unmasked data in a separate column. Access to the clear text or masked columns were controlled by which stored procedure was called by the application. By preloading the masked data, system performance was optimized instead of masking data as it is being returned to the application.

Bring Your Own Identity (BYOI)

BYOI, or Bring Your Own Identity, is a topic that came up during conversations with one organization that is working to build an identity proofing and credentialing service. The idea is that clients who are issued high assurance credentials would be able to use the credential at multiple internet properties. Said another way, if a user is proofed an issued an authentication credential by a well-trusted provider, they should be able to “bring” this credential to other sites.

I first wrote about BYOI in a blog post back in September of 2008 – you have to use the wayback machine (screen shot included here for convenience) to find it at this point. It’s great to see this idea catching on and to see constructive discussions about re-using high value credentials. To date, we have seen the most re-use of lower value credentials, such as Facebook.

byoi copy

Privacy requirements: country specific

We’ve seen privacy become a primary authorization requirement in the past year or so and this was strongly reaffirmed during our trip. Banks that operate in multiple jurisdictions are increasingly pressured to uphold country-specific privacy laws and regulations. For example, certain countries require that bank customer files and information can only be accessed by bank employees of the same citizenship or that are domiciled in the same country. These privacy rules are in addition to the business, security, and risk rules and other regulations the financial institution may be implementing.

With an ABAC system, it is much easier to incorporate region- and country-specific access rules. In an ABAC policy, rules can enforce all the security or privacy rules required because of the policy language used under the covers. In essence, you have a programming language at your disposal which is specialized for access control scenarios. Furthermore, policy analysis can be performed to validate that the correct controls are in place.

XACML and Dynamic Access Control in Windows Server 2012

May 25, 2012

Microsoft has introduced a significant feature enhancement to Windows Server 2012, Dynamic Access Control (DAC). This is big upgrade from the access control lists (ACLs) used in previous generations of Windows Server, giving enterprises a richer and more flexible authorization model at their disposal. The new functionality gives enterprises tools to more effectively control access to the vast amounts of data in Windows file shares, while complying with business, security and compliance policies. You can find an excellent introduction to Dynamic Access Control here and I expect Microsoft to publish much more information, as we get closer to the GA date for Windows Server 2012.

At Axiomatics, we have added a new feature to our core XACML engine – Axiomatics Policy Server – so that XACML authorization policies can be converted into a format recognized by the DAC function in Windows Server 2012. To implement DAC, Microsoft uses Security Descriptor Definition Language, or SDDL. The Axiomatics feature automatically translates XACML policies into SDDL format and loads the policies into your Windows Server 2012 Active Directory.

There are several benefits to the Axiomatics integration that will enhance Windows Server 2012 deployments, including:

  • Leverage a central authoritative source of access policies: XACML access policies that are implemented across other applications in the enterprise can now be applied to Windows Server environments.
  • Manage and control access to file server resources more easily: Policy languages provide, such as XACML, provide a more direct and flexible model for managing access to vast amounts of data spread across hundreds or thousands of servers.
  • Meet audit and compliance requirements more easily: An externalized and authoritative source for access policies means you have fewer places to audit and certify the access controls for critical applications and data
  • Report on who has access: Axiomatics provides advanced reporting tools to fully explore and validate your access control policies
  • Consistently enforce access across applications and platforms: Enable your Windows Server 2012 to participate in a broader, central authorization service. In this mode, enterprises can ensure a consistent level of policy enforcement across the environment – based on the single, authoritative source of access policies.
  • Best runtime performance: Windows Server 2012 performance is not impacted, since its normal internal access control mechanism is being utilized – there is no callout to an external authorization engine. This gives enterprises the best performance possible, but also provides the assurance that access control is being implemented according to centrally managed policies.
  • Increase value of your XACML investment: Integration with platforms such as Windows Server 2012 or Microsoft SharePoint 2010 extends the reach of your XACML authorization system.

If you are planning to visit Microsoft TechEd 2012, please stop by our booth in the partner pavilion for a demonstration.

Calling all Dutch speakers with an interest in XACML!

August 22, 2011

Hi, this is Felix Gaehtgens again, posting on Gerry’s blog. The Dutch government is thinking about adopting XACML as a standard, and until September 4, 2011 there is an open process to send in comments, which I encourage every Dutch speaker with an interest in XACML to do.

The Dutch cabinet has decided in 2007 to implement an action plan for the use of open standards and open software in government. A “Standardisation College” has been formed and tasked with looking at open standards and prescribing their use within the Dutch administration (“overheid”). This College maintains a list of standards on a “comply or explain” list. For future projects this means that tendering vendors and architects must either comply with the standards on the list, or give an explanation on why this cannot or should not be done.

Currently, it is being studied whether XACML should be put on the “comply or explain” list. The decision process is open and well defined, and works like this:

1. An expert group has met and compiled a document with their recommendation.

2. Following the publishing of this expert group recommendation document, there is now call to the public for comments and additional advice. This process closes on Sep 4, 2011.

3. The expert group recommendation and all of the public comments and reactions will be passed to the Standardisation College immediately after the Sep 4 deadline has passed.

4. The Standardisation College will then make a decision on whether to put XACML on the “comply or explain” list or not.

In short, the expert group met and looked at two standards: XACML and WS-Policy. Their recommendation was not to include WS-Policy in the “comply or explain” list. On XACML, the expert group recommended not to include XACML in the “comply or explain” list yet because the expert group thought that not enough experience existed with the standard, and they thought it was too early at this point. However, they stated that XACML is a very promising standard, and hence recommended to look at the issue again in one year.

I encourage every Dutch speaker with an interest in XACML to read the documents of the expert group, and to fill in the template for the public comments, and send it in before the deadline. I intend to do the same. In fact, there are several parts of the document which – albeit excellently written – may need some further clarification. Since the expert group admitted that they do not have much experience with XACML in the Netherlands yet – perhaps experience made in other locations and environments might flow into the process. I therefore encourage everybody who speaks Dutch and has some experience in externalising authorisation with XACML to send in their comments.

In the document, it is written that Centric (the government organisation tasked with the standardisation) is looking to take identity management, authN and authZ out of the applications and have them provided by a central facility. XACML is the ideal standard to do this. I believe that the choice is actually quite straight-forward. When authN (authentication), specifically federated authentication was being adopted, there was initially a bit of a “war of standards” between SAML 1, Liberty Alliance ID-FF, and WS-Federation. SAML 2.0 merged features of SAML 1 and Liberty Alliance ID-FF together into SAML 2.0. However IBM and Microsoft were still pushing for WS-Federation and initially refused to support SAML 2.0. Finally, SAML 2.0 came out on top, and even Microsoft fully support the standard natively.

With XACML, it is much easier. The standard is straight-forward and addresses externalised authorisation in a flexible, versatile and pervasive manner. There really is no contender. This is why it seems natural to me that XACML should be on the “comply or explain” list if authZ is really to be externalised.

The expert group rightfully states that there are many things to be thought of when externalising authorisation. They say for example that authZ between organisations will be a very interesting trend. The expert group recommends that perhaps a specific profile for using XACML could be defined. This is a very good idea. However, the enemy of the good is always the better. If you want to externalise authorisation, then you really need to start doing it rather sooner than later – because it will be more work retro-fitting externalised authZ into applications later. Hence my recommendation would be to start as early as you can. XACML is very flexible, and once you have managed to bring at least your new applications into line you have something to work with that gives you a lot of flexibility.

The expert group also started with a recommendation for an architecture but states that more work needs to go into this, saying that it would be a good starting point for a discussion. It definitely is a good starting point – I believe it is important however to point out again that XACML deployments give a lot of flexibility when it comes to the integration of applications – from coarse-grained to fine-grained. Several architecture models could be given as a suggestion, and there are many “good practises” available from existing implementations already (such as from our customers). But is all of this already necessary before a decision can be made to include XACML on the “comply or explain” list? There is the danger of “putting the cart in front of the horse” by saying that everything must be defined before a recommendation can be given which standards to use for externalising authZ. Why not just say yes, we want to externalise authZ, hence we’ll use the standard for doing this. As applications are becoming prepared to support XACML, a whole universe of possibilities opens up for providing more advanced authorisation services within and between organisations. But why wait with preparing applications to support this infrastructure? Waiting will only mean that there are more hard-wired non-standardised applications that will make it more difficult in the long run.

Perhaps this is why the expert group – admitting that there is not much experience with the standard – think that the time for XACML to be put on the “comply or explain” list may not yet be ripe.

I am not a real “Dutch speaker” although I can understand (depending on who is talking) and read it quite well after being exposed to a lot of the language in Belgium. I can speak it somewhat but it sounds “grappig”, and writing for me is very “moehelijk”. But I’ll do my best and have my Dutch friends look over my comments.

So if you speak Dutch, and have opinions/experience about XACML, please send in your comments so that the Standardisation College has the complete picture available when making their decision.

Here is the link again to the expert document, and the template for sending in comments.

XACML – so much more than some people can see!

June 29, 2011

This is Felix Gaehtgens and I am one of the latest additions to the Axiomatics team. My colleagues Gerry Gebel and David Brossard were so nice to offer me a space on their blogs. As a former industry analyst, I’m going to start here, and post my future more technical musings on David’s blog.

Speaking about musings, I just stumbled upon an article on heise.de from my former colleague Martin Kuppinger. The article talks about access management with the XACML standard and is entitled “Only good if you can’t see any of it”. It is published in German, and if you can understand that, you can read it here. Martin is a distinguished and very smart analyst, and I am honoured to have worked alongside him for more than three years at Kuppinger Cole where I covered the authorization field and in particular the XACML technology. His past and current musings – apart from this one article – provide an excellent insight into the current state of technology within the Identity and Access management field.

In his article, Martin wrote that XACML is a complex language. He expects that companies implementing XACML will have to confront a large set of many complex rules, and therefore the management of these rules is complex. He makes the point that XACML has to be “hidden” by tools because it is just too complex to use.

To my experience, nothing is further from the truth. This merely reflects some common misconceptions about XACML, and it also reflects some FUD (fear, uncertainty and doubt) floating around by some people without sufficient understanding of the XACML technology. What is important here is that customers need to have fully-fledged XACML tools to solve their complex authorization problems. Cutting corners and then calling those limited features “simplification” to make it “more user-friendly” mean that you don’t get all of the powerful benefits, and shouldn’t be an option for you. You need the potential of this technology to tackle the hard authorization problems in the real world. You will need to use the concepts of XACML to create compact and adequate policies. No short-cuts are recommended here.

XACML is a language used for access control, and it is very powerful and flexible. When I compare it to simple rules used in traditional SSO and RBAC-like access management products, I like saying that RBAC is like a simple text editor and XACML is like a word processor. If your needs are really simple then perhaps a text editor is enough. But if you want to create real documents, I’d highly recommend using a word processor.

The reality in XACML implementations is that you create a small set of policies that quite accurately reflects the overall business requirements. In many cases, you can almost “translate” a business access control requirement into one policy. This makes things quite simple, because you can easily edit the few number of policies to make sure that they accurately reflect what the business is demanding.

I’ve seen this already “at work” with several of our customers. They are really enthusiastic about the fact that they can create a fairly simple policy model in XACML to link their business policies together with data that already exists in the enterprise and deploy truly powerful and dynamic access control for their applications. It’s very cool to see this in action. That’s why I really disagree about the “good practise” of “generating” XACML from “simple” rules. Sure, you can do that, and there may be some cases when this could be useful, but then you are really missing out on those benefits of XACML that can truly transform your deployment.

Consider the other, more “traditionalist” approach. You have primitive and “simplified” access control rules, often in the form of “if user X has role Y”. You then need to model your business requirements in these types of low-level rules. Not an easy task, and it also means that you will need to maintain a whole new data repository to support your simplistic policy model. That is complex. And that is much more difficult to maintain and audit.

So XACML is “expressive” and “complete” rather than “primitive” because it allows you to do many more things. It allows you to define your access policy in just a few well-defined rules that are not difficult to understand, rather than in a myriad patchwork of primitive access control statements that become difficult and expensive to maintain and audit. This in my opinion is one of the greatest benefits of XACML. Maintaining you access control system in XACML makes it much easier, rather than more complex.

When I started at Axiomatics, I already expected that our customers would find it easier modeling their access control requirements with XACML rather than using a traditional role-based approach. Once I started talking to them, I was somewhat surprised to find out that many of them found it even easier than I thought! Sure, you have to learn a little (not too much), but this usually saves you so much more time and money because if elegantly side-steps a lot of the mess that you would otherwise have to confront.

Where Martin does have has a point is that XACML is based on XML, and nobody (except maybe for some hard-core geeks) would like to maintain XACML policies by editing raw XML files. But that’s obvious. At Axiomatics, we ship a GUI (graphical user interface) that allows you to define and test your XACML policies. It offers the full power and features of XACML in an easy way, rather than a limited “simplified” subset of possibilities that don’t go far. The learning curve with XACML is not steep, because it is actually very natural in the way that it allows you to express your requirements; and as with any powerful tool you’d be advised to take a bit of time to learn about the features at your disposal and real-life good practises that we’ve learned from our customers’ experiences. I’d be happy to discuss them with you – just drop me an email.

Take 2, talking authZ with Gunnar

January 28, 2011

Gunnar Peterson and I continued our discussion about authorization recently, this time talking about use cases, opportunities for architects, and how to get people to understand XACML.

GP: Gerry last time we chatted we talked about the overall architecture of XACML and some of the needs it fills for security architects in 2011. For this thread I wanted to talk about concrete Use Cases. The one Use case that seems to come up a lot when showing the value of XACML is healthcare, these are quite fascinating use cases that include fine grained authorization and privacy concerns, but this is not something that applies to all systems.

I wanted to get your thoughts on deployments where XACML use cases are for core access control and integrity. In my mind, XACML fills a need in both Mobile and Cloud use cases.

There are so many different Cloud Use Cases and deployments, but one area where XACML seems to solve a clear and pressing need is for fine grained authorization in PaaS and SaaS, where the following conditions apply.

* The Cloud Consumer would like to minimize use and control sharing of certain highly sensitive attributes, but would still like to shift the major parts of the software platform to PaaS/SaaS
* The Cloud Consumer (company) needs to store some sensitive data and funcitonality in PaaS/SaaS
* The user accounts are managed by the Cloud Consumer and the PaaS/SaaS relying party consume SAML tokens (or other)  at runtime

To me this looks like a core access control use case for XACML in the Cloud, where the run time access control resolves the policy dynamically based on the contents of the SAML token. Are there examples of this being done today?

GG: The scenario you are describing is covered by what I call the “anywhere architecture” that XACML addresses – see previous post on this topic. Access to cloud hosted data and resources can be controlled in a number of deployment configuration options. For example, you can have application specific PEPs at or near the resource, or utilize an XML gateway for the PEP. Policy servers (PDPs) can be installed on premises or hosted at the cloud provider. Similarly, policies can be managed where most appropriate and distributed to PDPs for run time enforcement.

When combined with a federation approach to authentication, you get the best of both worlds. That is, users can authenticate to their home domain regardless of where they are and access data based on policy – wherever that data is hosted.

We have been in discussions with some organizations that are investigating cloud hosting options for applications and data, but this is mostly in exploratory phases. What is reassuring to them is the fact that the XACML architecture does in fact cover such scenarios and and provides the flexibility they are looking for.

While not a cloud-hosted system, the Swedish National Health Care system does use a combination of SAML and XACML to control access to patient data. So your premise that healthcare is an excellent use case for XACML controls is certainly true. However the requirement to restrict access to specific data elements holds true across many other industry segments.

GP: In the Mobile case, we know that the devices are occasionally connected. So some session data will be cached  locally on the device – for when you go into the elevator, drive through a tunnel, or the stewardess tells you to turn off your phone before take off.
We also know that mobile device usability is pretty good but from a usability standpoint we want to minimize re-authentication for the user and extended authentication dances.

So both of these Mobile trends argue for delivering some content to the device that requires authorization out of band of the initial data flow – the ability to store a attribute cache and attach the policy to use if needed. This strikes me as right in the wheelhouse of XACML, have you seen these types of deployments?

GG: We are starting to see some interesting mobile uses cases emerge, but it’s still a bit early to make many concrete statements on how an XACML model could accommodate them. That said, here are some preliminary thoughts:

1. If a policy decision is rendered while the mobile device is connected, that decision could be cached locally for some period of time and re-used for a subsequent access request. This technique is useful for performance and efficiency when online, but also quite effective when you are offline – provided that the TTL limit is sufficient.
2. For full offline processing of authorization, you have to consider how much of the authZ apparatus can be tolerated on the mobile device. This includes the attributes and policies you mentioned, but also a decision engine of some sort. What might be more efficient is to preload decisions in some way. That is, if you possess a token or claim that indicates you are the owner of a health record – then you can view it.

GP: I used to struggle in how to convey XACML’s value proposition to people so I would just show them the mechanics and hope they could see it. But now I say XACML is useful in two scenarios- one where your data is on the move and two when you have more fine grained access decisions to make. I am sure there are other scenarios but those seem to be two quite important issues that many companies have to deal with today and XACML can play a role in addressing.

As to the data on the move, business has already decided that this is happening, whether its Cloud, Mobile or just good old fashioned Web apps. Its our job in security to catch up to where the business is going. The idea that the data can be in motion, and crucially that it can carry its security policy with it is a very useful property for a security architect to have at their disposal. You mentioned in response to the Cloud question that when using XACML plus a “federation approach to authentication, you get the best of both worlds”, this approach seems not only to be the best of both worlds, but one of the only ways to deliver on the flexibility of use case scenarios that the business is driving and the distributed technical architecture that runs those deployments.

Is there an end to end model (or models) emerging here?

GG: When you say end-to-end model, it makes me think of an architecture that is sort of tightly coupled. What has emerged over the last few years is the ability to piece together application and infrastructure components based on a number of important standards, such as SAML, XACML, OAuth, WS-Security, WS-Trust, etc. The existence of standards makes it more feasible to build implementations that are flexible enough to support the kind of mobile models you are describing.

Data on the move is one issue, but “access on the move” is another perspective that I think should be treated slightly differently. Certainly when a data element moves from protected storage to some other location, you may want to attach policy that controls its usage downstream. Access on the move is at least as equally compelling because in this case you have power users demanding the ability to perform their jobs from any computing device regardless of where they are located. Subsequently, it can be difficult to build an access model that applies the same policy rigor across all these channels and devices.

The challenge for security architects is develop solutions that accommodate mobile data and mobile workforces, instead of just saying ‘no’.

GP: As a security architect, I take it as a given that authentication happens in one place and authorization happens in another. As a general rule of thumb I want my authentication process to happen as “close” to the user/subject as possible, where they know the most about the user; and I want my authorization processes to fire as “close” to the resource as possible, where the authorization process has the most specific knowledge as to the authorization request. XACML helps me resolve the back half of that problem.

It strikes me that the combination of SAML to ferry the authentication/attribute assertions to Anywhere architecture (XACML) on the resource side closes some gaps that most security architectures have today, lots of system have strong authentication, some systems have good fine grained authorization, but almost all systems have systemic breakdowns in the middleware plumbing between those two, and those two domains – authentication and authorization have to work together.

Are you seeing the drivers for XACML being around the resource domain or enabling an end to end model?

GG: There are multiple drivers for externalized authorization based on XACML, but lets focus on a couple. First there is the audit and compliance angle (I recognize that the industry has beaten this issue to a pulp in the last couple years…). As someone told me recently, “if we can implement externalized authorization, then we will actually have a chance to answer auditors’ questions when they ask about access to these applications.” This is still a big issue for organizations, particularly those that are deploying more sophisticated applications – they must have more granular access to the application’s functions and they prefer to do it in a standards-based way.

Second, an organization’s most precious data is exactly what outsiders like partners and customers want access to. A policy language like XACML allows you to share exactly the right data and nothing more to the right users. You could say this is resource domain focused. Standards like SAML play a role because an organization doesn’t want to, and shouldn’t, manage credentials for most outside users.

GP: Role based access control has done well in terms of adoption for many reasons, but I think one important reason has little to do with technologies, its that a Role is a real thing in an organization. Its easy for people to grasp that a DBA or a nurse or a stock trader should have a different set of privileges and that we can aggregate them into Roles. In ABAC, we have a far more powerful, generic framework that can build much more robust authorization frameworks than RBAC. The generic part of ABAC is what gives it its architectural power, but in terms of communicating them it makes it much harder because you don’t anchor the description on a fixed concept like a Role. It seems that patterns could fill this gap, but many of the patterns we have seen so far are things like delegation, which is important but refers to a domain specific authorization concern. Are there patterns that you are seeing emerge that help map some ABAC capabilities to organizational Parties, Places and Things?

GG: There has been a similar discussion on LinkedIn (http://linkd.in/ekLLqo) that has more than 180 comments, so far. The RBAC model has a huge head start in terms of mindshare – it has been promoted for something like 30 years. As you point out, a role is something that people recognize and it encapsulates at least a high level notion of what privileges should be for a person assigned to that role. One of the challenges with roles is that they are often not granular enough: doctors can view patient information, but it should only be for the patients assigned to them. Nurses can update patient status, but it is only permitted while they are on duty, from the nurse’s station, and if they badged into the clinic. These kind of rules can be difficult to represent in a role or in an access policy. With an ABAC language like XACML, it is very easy to represent organizational or security policies in the XACML language. While it is not as “human readable” as a role, XACML policy is a much more comprehensive way to represent access policy where roles are one of the attributes that can be utilized.

GP: As much as people think about computing technology, tools and protocols, real world deployment is all about people and process. How do you get organizations to grok XACML? What kinds of things do they need to do in the development and operational processes to get benefits from XACML?

GG: First they need to buy into the notion that externalized authorization is the right architectural approach for building and deploying applications. Fortunately, the number of architects thinking this way is growing and they are causing software makers to change course. Once you embrace, here are three important things to consider:

1. How will applications interface with the XACML service? In essence, this means how will the application construct an XACML request and process the XACML response for access decisions. Each application style is a little different in where the necessary attributes (subject, action, resource, environment) are stored so the PEP may need to be adjusted. In some scenarios, an XML gateway can be a low footprint way of dealing with web services applications.

This also implies that developers and application owners need to buy into the externalized authorization model. Security pros will recognize this point as critical – think of how many times you have attempted to sell developers and app owners on a new idea, your mileage may vary.

2. Who will author and manage XACML policies? As with other access policies, administrators will work with application and security experts to construct XACML policies. Administrators learn this skill fairly quickly, but they do need some training and guidance at first.

3. Where are the attributes? Since XACML is an attribute based language, organizations may need to do some work to improve the care and maintenance of privilege giving attributes. For example, if a request comes into the PDP that Alice, a doctor, wants to update a patient record – the PDP may need to find out more information on Alice. Is Alice affiliated with the hospital where the patient is located? Is Alice the patient’s primary physician assigned to the case? This information could be stored in a directory, database, patient record system, etc. Further, if these attributes are used to grant access, they must be properly maintained to ensure accuracy.

PayPal Selects Axiomatics Access Management Solution

November 18, 2010

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.

If the shoe fits…

March 9, 2010

Of course Jackson’s post on SAML vs. XACML for authorization caught my eye and I wanted to add some thoughts…

First, I don’t think it’s a Betamax vs. VHS zero sum game. Exchanging attributes (claims) via SAML tokens is a reasonable place to start for relatively simple application authorization. I will resist the urge to respond as a purist and won’t point out all the extra benefits you get from going to the XACML model :-). What’s important is finding a practical approach that is suitable for the requirements at hand and complementary to existing IdM infrastructure.

At Axiomatics, we do talk to organizations that want to get deep into sophisticated authorization services – and we think XACML is the right model for such scenarios. However, we acknowledge it is not a one-size-fits-all solution.

Where Microsoft goes with authorization will be interesting to watch. They have already sent a very positive signal to the industry with their claims-based approach to building identity-aware applications. In the mean time, XACML based authorization services are very compatible with claims applications.


Follow

Get every new post delivered to your Inbox.