James McGovern asks whether federated identity might require (at least sometimes) federated authorization. I think this is a pretty good question and one that is not easy to answer. My initial take on this would be that federated identity should not require federated authorization, assuming that I understand correctly what federated authorization really is.
For simplicity’s sake, let identity be just a bag full of attributes (e.g. e-mail address, names, phone number, etc.). An indentity provider is then nothing more than a service that asserts that certain attributes have a particular value for a given digital identity. A relying party (i.e. a service provider like e.g. AmazingBookStore) can choose to trust such an assertion – either in full, or just certain parts of it. At the end of the day, the relying party will have to determine the level of access based on the type of assertion and the content of the “attribute bag”. As such, in this case authorization is local.
If authorization is to be delegated to another point (as in e.g. the XACML model), the relying party forwards it to a policy decision point, where the contained attribute information and additional attributes the PDP might obtain are evaluated according to a set of policies.
Now what is federated authorization? If I understand it correctly, it would be a scenario where you trust access level decisions to your resources to a third party (e.g. you would let YahaPortals.COM decide whether or not a user can get access to data you own). I am tempted to say that the risk that YahaPortals has about a false negative or false positive decision is quite substantial, particularly in our age of increased liability.
While there might be some use cases that do (or will) require such a model, I would argue that XACML provides a pretty substantial technology base for a federated authorization system, should the need arise. Some additional elements for such a system (e.g. trust establishment, crypto, etc.) could be either profiled or application specific.
UPDATE: As usual (at least in the last couple of weeks), I am quite behind things. James apparendly commented on quite a few blogs (hmm, was that related to IIW tagging … noooo, can’t be) and got some pretty substantial answers from Pat, Conor, and Paul.
Hi Gerry,
"the relying party again obtains the attribute information, but forwards it to a policy decision point" – Noooo – the relying party (in this context, the policy enforcement point, or PEP) makes a request of a policy decision point (PDP) – e.g. "Can this guy look at this secret stuff". The PDP might itself request attributes from an attribute provider to make this decision, returning a yes/no answer to the PEP. One of the strengths of this model is that the RP doesn’t see the actual attributes at all.
Cheers, Pat
Well, you are correct in the fact that the PDP can (and probably will) obtain additional attributes for its decision.
However, the PEP (or more specifically the context handler) *must* include some elements (<Subject>, <Resource>, <Action> and <Environment>) in the <xacml-context:Request>. Each of these can have any number (including 0) of <Attribute> nodes, such as e.g. the email address for the <Subject> or a URI for <Resource>.
Thus, while <xacml-context:Request> can be formulated without any attributes identifying the requestor, there are also quite a number of use cases where there will be identity attributes within the request to the PDP.
(Note: This comment refers to XACML 2.0)
OK – yes – there have to be some attributes to identify the principal (though I don’t think of those as attributes for some reason). I think we’re in agreement though that the IdP wouldn’t send, say, the principal’s department code and purchasing limit to the RP for the RP (as PEP) to forward them to the PDP with a reference to some requested action/resource. Rather, the PEP would send whatever identifying attributes it had to the PDP (along with a reference to the requested action/resource) and the PDP would retrieve whatever attributes it needed to make the decision.
In short – I think we’re saying the same thing using slightly different words. 🙂