Restrictions on a credential may include the
following:
- Limited number of uses. A credential may be set to expire after
an arbitrary number of uses.
- Limited lifetime. A credential may be set to expire in a
shorter amount of time than the default.
- Service validity. A credential may be restricted to a subset
of potential services. For example, a credential used to login to a
web based email service might be scoped only for that service, and thus
not valid to access student grade information.
- Authorization. Unlike other restrictions, authorization
restrictions are imposed when the specific use credential is validated.
Upon successful verification of the credential, WIND will perform an
authorization step in accordance with the requested query and local
release rules.
Restrictions may be imposed by any of the following, in order of precedence:
- WIND configuration. Restrictions may be associated with the
service requesting the credentials.
- User configuration. Users may be offered the option to adjust
the restrictions when authenticating. Users may not set or modify
authorization restrictions.
- Site request. The site requesting authentication may also
restrict what a credential may be used for.
For reasons of data integrity, each WIND host within a given site's
installation will maintain its own database of valid credentials.
Thus, when a user authenticates via WIND, any credentials issued may
only be validated against the server which issued them. In the event
one server becomes unavailable, the user may be required to
reauthenticate against an available host.
In order to validate credentials successfully when more than one host
is deployed, WIND will encode a hint in the credentials it generates.
The format of the hint need be known only to WIND. The user's web
browser or the site requesting authentication need only know the
general published name of the WIND service, and need not know about
specific hosts that are responding. If the browser or site connects
to a host that does not have the user's credentials in its own
database, the WIND server on that host will parse the hint and proxy
the request to the correct host.
As more hosts are added, the overhead of a WIND verification
transaction approaches two hops. The likelihood that the browser or
site will connect to the correct host decreases as the number of hosts
increases (with 2 hosts: 50%, with 3 hosts: 33%, etc), thus increasing
the likelihood that a second connection (from the initial WIND host to
the host with the information) will be required.
In the debate of Certificates vs. Tokens, the WIND approach favors
tokens. While certificates may be verified off line, the authenticating
service needs to maintain an appropriate CA public key and must correctly
track use of junk certificates to prevent replay attacks. Tokens require
on line verification and are a point of failure, but provide auditing of
use, move the replay prevention to a central monitoring point, and require
less user education (in comparison with personal certificates).
In the debate of Basic Auth vs Cookies, the WIND approach favors
Basic Auth. Both offer essentially the same level of security. Basic
Auth eliminates one level of complexity (session ID) at the expense of
offering configuration options on the same screen as the login dialogue.
However, Basic Auth cannot be reliably implemented, as browsers cache
passwords until they are reentered (regardless of if the password has
been rejected by the server).
WIND is based on Yale's Central Authentication Server.
