Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...As ever, Eve is special, she rated a slightly modified version.
Not sure about the mechanism, but my thoughts regardless.
If you look at the P*P (PDP, PIP, PEP, PAP) model that SAML popularized, in theory you can distribute them any which way across the boundary between two policy domains. Typical federation models allow for the PIP (or at least one of them) separate/distant from the PEP and PDPs guarding some resource - the PIP supplies information (typically in the form of user attributes) to the PDP that feeds into the authorization decision. Shibboleth is a good example of this model.
In principle, you could have the PDP also distant from the PEP (which necessarily has to be 'close' to the resources its protecting) but its a special kind of PEP that will listen to such a PDP. This is what I expect James is referring to when he says 'federated authorization'.
In a previous life, my Entrust colleague at the time Carlisle Adams and I looked at the different permutations - the work can be found in an appendix to a GGF paper called "Conceptual Grid Authorization Framework and Classification".
The permutations we identified are shown below (with terminology aligned to the Grid world - the paper explains).
1 comment:
I don't know what "federated authz" is, but I do know that Shibboleth does not refer to terms "PIP" or "PDP", nor does it implement a PDP in any way. It is up to the protected resource to consume the exposed attributes and make an access control decision.
FWIW, Globus Toolkit (http://www.globus.org/toolkit/), on the other hand, does subscribe to the PIP-PDP model for attribute-based access control.
Post a Comment