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.
Analyzing Identity 