In JIT provisioning I looked at how you could create a just in time provisioning system. In that posting I discussed the case from the identity hubs point of view. Now lets take the other viewpoint and be the app instead.
As the app you basically have made the choice to trust that the identity hub has done a good job of doing the authentication and authorization. You don't really have any other choice than to trust the hub. If you are an application that doesn't need to persist state between session your life becomes very simple. You serve the content based on the information provided in the request.
On the other hand if you need to persist state you basically need to create a new account every time someone with a new primary key attribute shows up. You would also need some kind of mechanism to invalidate accounts that haven't been used for a while as you would otherwise just accumulate active accounts indefinitely. The disablement could be done through straight ageing (no usage for one month results in the account being put in disabled status or perhaps even deleted) or by querying the identity hub. The query could either be a delta recon (what have been disabled/deleted since I last asked) or a full recon (get all accounts from the hub and see what accounts are present on your side but not on the hub side).
One interesting aspect of this is that in a company to company situation it should be of interest to the hub company to be able to show the application partners what the hub authorization logic really is as they are in fact trusting the hub blindly. This is a very interesting use case for XACML as it is much easier to review some XACML than hundreds or even thousands of lines of Java/c#.
No comments:
Post a Comment