OCLC achieves authentication and authorization using several components in concert, these include: User Authentication and developer keys (WSKey).
Our User Authentication System lets you identify the current user via SAML even when their institution does not directly support SAML. The result of integrating with and invoking the User Authentication System is primarily the acquisition of a user identifier (pair) that is understood by both client and OCLC systems.
We use our WSKey System to authenticate institutions and partner organizations, not individuals. Once WSKey has established a ‘secure pipe’ between strongly authenticated institutional identities, that pipe is used to pass the User information established by the Authentication.
When User information is passed down a ‘pipe’ secured by WSKey it is done so in the form of ‘principalID’ and ‘principalIDNS’ in the Authorization Headers of the requests.
Application Level Authentication and Authorization is performed by WSKeys. WSkeys can be used in three different ways to Authenticate.
WSKeys belong to a specific user and typically limit access by
In addition to application level authentication and authorization, some OCLC web services perform verification at the user level. Clients can identify users by sending principalID and principalIDNS parameters as part of an HTTP request to a web service. The principalID represents a username and the principalIDNS, or principal identity namespace, is a context for who authenticated a user. Clients will obtain principalID and principalIDNS values as a result of authenticating users against the User Authentication System.
A client can send principal information as URL parameters, but the preferred way to send principal information is through key value pairs on the request headers as in the examples below.
A user represented by a principal ID and namespace will have associated roles and permissions in the OCLC identity management (IDM) system. These roles and permissions will be used to make authorization decisions that determine the success for a client’s request to access or modify data.
Example HMAC Signature Authorization Header:
Authorization: http://www.worldcat.org/wskey/v2/hmac/v1 clientId="tsFsoBXToV1uR8GEMJCcxz9NYpVvutsA5cJAD9cnKUc4FGYEntM6UkcIVlYp4ZhYFteVLAxOWJDUV85W", timestamp="1361306811", nonce="762343395744465450467911322335", signature="2DwPAIYqlCOH9xCHM7PSnOBoVKk/PHrHPeIGmmEK/AI=", principalID="8eaa9f92-3951-431c-975a-d7dfkd9rd131", principalIDNS="urn:oclc:wms:da"
Example Access Token Authorization Header:
Authorization: bearer tk_123456789 principalID="8eaa9f92-3951-431c-975a-d7dfkd9rd131", principalIDNS="urn:oclc:wms:da"
The OCLC Developer Network supports the use of OCLC Web Services—a set of tools and APIs that expose data and services for WorldCat and our member libraries and partner institutions or companies. learn more »
© 2010 OCLC Domestic and international trademarks and/or service marks of OCLC Online Computer Library Center, Inc. and its affiliates