Rather than worrying about the RBAC profile of XACML or about
where attributes come from, and a slew of other complex technical matters,
Keystone provides users with a sleek, easy to use interface that abstracts away
all the identity “goo”. Business users simply need to define their
policy and go about their business. They do not need to understand complex
concepts.

People that only care about RBAC (role-based access control) can
use it, and people that want pure ABAC (attribute-based access control) can use
it. The beauty of Keystone is that it allows you to use both models without
having any mismatch in the way you think. Everything fits naturally.

If you want to learn about XACML give us a shout! BiTKOO offers a
free training session in our offices in Los Angeles. We can also send our
trainers to you!

Here is my definition of cloud computing:  you read it here first, even though I’ve been saying it since 2003. In fact, that is the reason I invented Keystone; more about that later.

Drumroll…
Cloud computing is the ability for a third party to store, search and compute a client’s data in a scalable, resilient and secure way, without the third party’s ability to look at the data, even with a court order!

Now, that’s worth devoting one’s life to! And that is exactly my life’s professional goal. Can’t be done? Nonsense! I will give you an example of this model that is already in use today, albeit simpler: Why do you trust e-commerce? Is it because you trust AT&T, Sprint, or other intermediaries that shuttle the data from your browser to your bank or merchant? Or is it because you trust the SSL protocol and algorithm? Hopefully the answer is the latter. The SSL algorithm is open and does not hide behind obscurity but rather it uses a well-defined, easily understood (my wife disagrees with this one) protocol/algorithm. Because there is a well-defined, open standard for doing secure communication over the insecure internet we now have e-commerce. It is great! I just ordered a pair of sneakers online and I didn’t have to establish a contract with all the telecommunication companies moving my data from my browser to the merchant. I trust the mechanism, not the service providers.

I arrived at this conclusion in May 2003 when I asked myself how I can simplify application development greatly. I observed, like many others that software is all about layers of abstraction. It started around 1947 with machines that required the operator to flip switches. It moved on to assembly language, then moved to simple procedural languages, object-oriented languages, component-oriented frameworks and the latest (circa 2003) was web services. I said to myself: “if I draw a diagonal line from 1947 all the way to 2003 and continue the line upwards and to the right all the way to 2020, what would a day in the life of a developer in 2020 look like?” I decided to dream about being a developer in 2020. What I saw in my mind was very nice and simple. I called it NGI – Next Generation Internet. It was comprised of an interface I called INGI. Here it is, taken from some experimental code we developed recently:

using System;
using System.Xml;

namespace BiTKOO
{
interface INGI
{
Guid Put(XmlDocument data);
XmlDocument Get(XmlDocument query);
Guid Monitor(Uri callbackAddress, XmlDocument query);
bool UnMonitor(Guid id, XmlDocument securityContext);
}
}

This is the only way I want to talk to the cloud. The cloud provider should expose this interface and nothing else. I should be able to PUT any data and get a unique identifier. I can then take that unique identifier (token or pointer) and store it locally on my phone or store it in yet another PUT command in the cloud. What’s in the data parameter of PUT? Anything! The data parameter will contain an envelope that has sections for security, authentication, authorization, encryption, retention policy, and any metadata that tells the “man behind the curtain” what to do with the data. This can be extensible to include where to publish the data to, what to do with older data that the new data replaces, etc.

The GET method would get me data back but only if my QUERY contains the right search criteria and additional data such as my credentials, claims, context, certificates, etc. So I would construct a query document that has everything the “man behind the curtain” needs in order to go fetch me my data. It might include cryptographic elements that are needed for the “man behind the curtain” to search, compute and otherwise retrieve my data.

Monitor is my way to tell the “man behind the curtain” to have an ongoing query that will cause a document to be posted to the URL indicated by callbackAddress. An example would be a stock price or a blog. I would issue a query like this (symbol=”GE” return=”PRICE”, condition=”PRICE<30.00” frequency=”hourly”). Of course the query language here is pseudo and provided for simplicity in understanding the concept of NGI. Formalities will need to run throughout the system for it to work.

What I just described above is my view of the cloud and I have ZERO DOUBT that this is how IT will be done in 2020. What are the advantages? Developers don’t need to care about:

· How many instances of a server to run
· Where is the server
· What OS is the server running
· What database architecture is the server running
· Is there a load balancer
· How to encrypt the data
· How to efficiently search the data
· How long to retain the data for and how to manage that
· You get the idea…

All the items us as developers need to worry about today will seem plain silly once we have NGI. When you type a search on Google you don’t care about what’s behind the curtain: Linux, map-reduce, etc. You care that you type “Chinese Food” and presto. NGI can be thought of as “Google for private data”.

If you read carefully above, what is not immediately obvious from looking at the interface is how the service provider will be able to store, retrieve, search, and compute my data without being able to look at the data. We are working hard to make this a reality. When I started down this path in May 2003 I drew 45 boxes that were needed to make this happen. They included authentication, authorization, encryption, audit trail, replication, data sharding, and many more boxes. I decided to start alphabetically (just kidding) with authentication and authorization; thus Keystone was born. Without a doubt I can see the light at end of the tunnel and I am getting very excited. We have standards such as SAML, XACML, and others that will play a role in getting us as an industry to NGI. When we get there it will be fantastic and will liberate us to think about how to make software do even more amazing things without having to worry about the plumbing that most people re-invent on a daily basis. If you agree or disagree or want to help get us there, drop me a line and let me know what you think. I can be reached via email at Doron@BiTKOO.com