There are flavours of the above, depending on where the above logic is defined, where it's enforced, and whether all actors are cognizant of what's going on.
If the logic is captured and enforced at the provider hosting the resource in question, then it's a local affair and effectively boils down to an authorization rule at that provider. (Liberty People service is an enabler of this scenario, allowing such local authorization policies to be defined in terms of non-local identities.) In this scenario, even were Entity B to appear at the SP as a result of an SSO from an IDP, that IDP need not be aware of the policy.
If however the resource in question is Entity A's IDP account, then there are potential non-local ramifications should Entity B attempt to use the privileges to access Entity A's resources at other SPs. As an example, if I've specified to my bank that my wife has full access to my account, and that bank account has been federated with other SP accounts (e.g. mutual funds), then 'full access' might mean my wife could access my mutual funds investment account through my bank account if and when she authenticated to the bank.
In this latter case, if the bank IDP creates an assertion for the mutual fund SP that claims my wife is me, that's an impersonation model.
If instead the assertion carries both my wife's identity (even if anonymous) as well as my own and expresses the privileges that have been granted by the latter to the former, then that's delegation.
And of course, depending on the technology, A can always give their credentials to B.
The following lays out these 4 models (the blue dot represents where the 'A says B can do X to Y' rule is enforced.)
No comments:
Post a Comment