OKI Common Services Authentication API.

The authentication process gathers required credentials from an agent, vouches for their (the credentials') authenticity and introduces the agent to the system. The OKI authentication API abstracts this process allowing the OKI application to determine and manipulate the authentication status of an agent without having to manage the details of a particular institution's environment.

The service must work over various kinds of authentication infrastructure. Many institutions already have, or are striving for, central authentication. Examples of technologies in play include Kerberos, x.509 and cookie-based single sign-on technologies such as webISO (http://middleware.internet2.edu/webiso). Increasingly institutions will be reaching beyond their traditional boundaries and operating in a universe of federated security domains, as for example with Shibboleth (http://middleware.internet2.edu/shibboleth).

Not only must the service handle different methods across the range of institutions, it must also handle these within a given insitution. Some applications might rely on userid/password; some on certificates; most users authenticate locally; some might remotely. This range is represented in the interface using the concept of authentciation type. There is typically a default type at an institution, the common method of authentication for the generality of use. Additional types are available to accommodate the rest.

An agent, a human or inhuman principal, is authenticated according to one or more such types. There are, indeed, situations when an agent may need to be authenticated more than once in a session. This can happen when an agent switches from one type of activity to another. Checking the class schedule, for example, may require userid/password, while updating the final grades may require an X.509 certificate issued with a high level of assurance.