James McGovern looks at Cardspace and asks:
It seems as if CardSpace can support claims-based security checks which is a little different than role-based security checks. Are there thoughts from the security community such as Gunnar Peterson on this?
Claims based access control (CBAC...or ABAC assertion based access control if you prefer) definitely differs from RBAC. A classic RBAC model maps subjects to roles to entitlements for certain objects. This sounds a lot easier than it is in practice. Many organizations look at the model and say "hey I know that if you are a DBA then you are in this role and you should get this type of functionality, and if you are a sales person you are the sales role and get only these functions." The problem is that mapping, while not always trivial, is by far the easier. Mapping all the object to entitlements and roles is very difficult in a distributed system.
Basically you have all of the problems that the O/R mapping people have and almost no tool support. As a side note, we know that O/R mapping is the Vietnam of computer science, keep sending troops and resources, but good luck solving the problem. How RBAC is typically practiced in distributed system often quickly devolves into a game distributed impedance mismatch. Roles can still play an important part in the overall access control model, but they are not generally sufficient alone.
Enter CBAC/ABAC.
Instead of end to end mapping subjects and objects across multiple layers, we'd rather focus on the claim (as WS-* would have it) or assertion (as SAML would have it). In this space we are less concerned about the object-entitlement-role hierarchy and more concerned about the token(s) and the policy. The object (data, component, whatever) is still in play obviously and it is protected by a Policy Enforcement Point (PEP). The PEP has the advantage of being able to form fit to what it is protecting. If it is a Java object then it may be an interceptor pattern, if it is J2EE then it may be the container. In true loosely coupled fashion, you create a relationship between the PEP (and its own internal policies, rules, etc.) and the object, but do not have to hard wire the subject -role-entitlement-object together.
The PEP then is responsible for token validation, session validation, associating the object/rule/policy stack with token and the session, and coming to some sort of go/nogo decision (PDP). The PEP may never see a group or role or anything of this nature (these may be used for convenience), and instead enforce the policy on the token and the policies wrt granting access to the object. From a service provider view, the PEP structure looks like this:
Internal to the PEP there are a set of workflow pipelines that fire the policy rules, it should be noted that these are not typically object oriented designs in nature, but can be hidden from the rest of the app in an interceptor pattern. I will exlpore some internal PEP workflows in a future post.
So the net result is that the PEP is form fit to that which it protects *not* to the subject. This in turn allows us to form fit the token to a variety of subjects and request types - CardSpace being a good example, but there are lots of others - smart cards, otp, oath, and so on. Then optimization can occur both on the PEP side and improve usability and strength on the subject's token side. The only thing binding these two (is not binary runtimes) but the request message, which points again, to why message level security is sine qua non going forward in security.
Architectures open up security holes when they cannot use strong authentication to generate tokens, cannot protect the tokens in transit using crypto and signatures, and cannot ensure that the request and tokens are bound together correctly.
Update: Read the thrilling conclusion in Of Claims and Coins (or For a Few Dollars More)
