Difference between revisions of "Authentication Protocols"
(→Solutions) |
(→Context) |
||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
| − | Since [[Kerberos]] was released at MIT in 1999 as a means to allow [[Single Sign On]] by students and staff to the variety of systems available at the university | + | Since [[Kerberos]] was released at MIT in 1999 as a means to allow [[Single Sign On]] by students and staff to the variety of systems available at the university. Since then the combination of one user sign on to a variety of different services has been promoted as necessary in the variety of network services now available to users. There are two distinct cases and a wide range of intermediate cases that are addressed by authentication protocols: |
===Captive users and services=== | ===Captive users and services=== | ||
Revision as of 21:33, 11 July 2018
Contents
Full Title or Meme
A collection of Authentication protocols are compared and contrasted.
Context
Since Kerberos was released at MIT in 1999 as a means to allow Single Sign On by students and staff to the variety of systems available at the university. Since then the combination of one user sign on to a variety of different services has been promoted as necessary in the variety of network services now available to users. There are two distinct cases and a wide range of intermediate cases that are addressed by authentication protocols:
Captive users and services
At MIT and at most corporations there is a pre-existing legal agreement that is signed by all users that applies to all services.
In such a closed system in makes sense to allow Single Log Out so that a user can close their connection and go home for the day.
Federated or Open systems of users and services
In such an open system it is not often helpful for a user to be signed out of all web sites when they chose to sign out of (say) the purchase of concert tickets.
Problems
- Users do not want to be forced to create a distinct sign-on user name and password (their credentials) at every site they visit.
- It is proven to be insecure for users to be required to have distinct sign-on credentials as they will generally reuse their credentials at every site possible.
- Developers select a protocol based on the tools available for implementing the protocols and only later start adding requirements like Single Log Out. As are result they wind up using a protocol that is not designed for the system that they are implementing.
