|
|
|
Federated Authentication
It's not a question of why will federated authentication become more popular but rather: why is it that it is not more prevalent in business? There is no doubt that there is an increasing movement towards increased federation, what's surprising is how long it is taking.
Part of the reason is the inherent distrust between entities doing business and part of the reason is the difficulty in assigning costs, in other words - who is going to pay for the technology. As we shall see, these reasons are behind us now and over the next few years we will see extensive and significant federated authentication environments.
WHAT IS FEDERATED AUTHENTICATION?
The premise of any identity management environment is that someone is going to manage the identities. This can be an extremely time-consuming and onerous activity. You have to make contact with the person, you have to collect and verify their details, you need to store their details, then you must assign access rights to them - and then they move house!
Keeping track of people and keeping the data you are storing about them current is an on-going and expensive undertaking.
What if you could get someone else to do it? If it's doctors who access your system, why not let the medical board maintain each doctor's details; if it is travel agents, why not let the travel agent association maintain their identity; if it's taxi drivers who access your site, should not the licensing board for taxi drivers maintain their identity record?
This is where federated authentication comes into play. In a federated authentication environment the most logical organization to maintain identities does just that and service providers trust the credentials provided by these organizations.
In a federated authentication environment there are identity providers and service providers. The identity providers are the associations or certification bodies who agree to attest to their member's identities, furthermore, each member can control the identity detail they wish the identity provider to release to each service provider.
An organization providing a service that requires users to be authenticated accesses the identity provider and obtains the credentials of a user requesting access to the service. These credentials are compared to the service request and if the user is satisfactorily authenticated the service is provided.
The primary reasons why a customer employs ICA are:
| |
• Vendor independence |
| |
• Understanding of the complex technical requirements and environments in delivering Single Sign On, RBAC
(Role Based Access Control) & Unified User Management |
| |
• Clear knowledge and experience in evaluating different vendor capabilities. |
|
| |
|
|
|
 
|
|
