Who Do You Trust?
I have been working with a customer recently who needs to allow users at business partners access to some of his applications. This is different from the general web case in that their is a business relationship between the companies, in the general web access case there is not necessarily any relationship between the parties.
The question is how best to allow end users at the partner access to my customers systems. Put it another way, who does the company decide to trust?
Lets think about some of the options available.
We could have a single account for each partner
This has the advantage that it is simple to set up and administer. However if multiple end users at the partner access the application then we won't know who the real end user is, there is no audit trail. We can identify which company accessed the application, but not who within the company.
In fact it is worse than that because if an employee who knows the credentials required to access the application leaves the company then he could potentially still access that application.
We could have an account for each partner user.
This means that we now have an audit trail. However we have an administrative overhead of managing all the end users at the partners who access our application. We also are reliant on the partners requesting us to remove access from users who leave the company.
We could control the accounts centrally but allow the partners to manage their own users.
This would create two types of users at the partner companies. Administrators would be able to create new user accounts and grant them a limited set of priviliges on the application. Normal users would just be able to access the application but would have no user administration rights. This is a delegated administration model.
This has the advantage that we can now track individual users of the application bu we don't have to administer them centrally, the partners will administer their own users.
The administrative overhead of this is not much different from the one user per partner approach, although we would probably have to worry about several administrators per partner although this privilige could be delegated as well.
There is still the problem of users leaving the company and still having access to the application. In fact the problem is worse because now a rogue user can leave the company and still have administrator priviliges.
We could federate the identity.
In this model we rely on the partner company to assert who the user is and what their role is. We centrally manage roles and partners and allow the partners to manage their own user populations.
This requires the partner to authenticate the user as part of their own environment and then they pass the username and role across to the company as an assertion of the users identity.
This reduces the problem of users leaving the company because now to access the application they must be able to authenticate to their previous employers system and also access the federation server that can assert their identity to my customer.
So as you can see there are a lot of options. The first couple of options work well when there are only a couple of users accessing the application per partner. The third option works well for larger number of users at the partners. The fourth option of federation works well when there are many end users at the partners, especially when there is a lot of "churn" of those users as may occur in service or retail industries.
All the above options can be improved by suitable network level security, but we shouldn't really rely on network security to secure our applications if for no other reason than that the applications themselves also need to know about the users.
The Oracle Identity Management Suite supports all the above options and more, maybe I will look in more detail at suitable architectures for the above in a future blog.
