# Authentication and Authorization

This section provides an overview of how the service handles authentication and authorization.

The Document Service is integrated with the claims-based identity system used throughout Wolters Kluwer Financial Services' distributed applications. This model requires that all data access requests pass through the core services where they are authenticated by a Security Token Service (STS). In this model, the STS issues security tokens (or software tokens) as part of the claims-based identity system. Associated with the certificate installed in the local certificate store is an Identity Certification token (an Act-As token).

The Document Service, as a secure application within the Wolters Kluwer Financial Services application development domain, does not perform authentication directly (for example by validating credentials submitted on a request message) but rather redirects the client to the STS. The STS then performs authentication of the client and issues a security token. The Document Service validates that the security token originates from a trusted STS and then authorizes the request accordingly.

## Named User Authentication

A user (a named entity) submitting a request authenticates through the SSL Certificate and Identity Certificatation token installed on the host server (the DocGenServices server) in the target environment (CT, IN, CI, et al). In this case, the user does not need to perform any action. If they are set up in administration with the appropriate rights, they will be able to authenticate and submit a request.

At a high level, the workflow might look like this. When an unauthenticated user submits a request message to the service, the request is redirected to the identity provider (STS). Once authenticated, the identity provider redirects the request back to the original application with a token that the original application (the service provider; in this case, the Document Service) verifies. Once the token is verified, the requested resource is served by the service.

## Application Authentication

In cases where the service is employed to access content from the Expere environment, authentication and authorization occurs with an application or line of business (LOB) rather than a named entity. If the calling application is defined as an application from an administrative perspective, the service authenticates the service account through the Application Identity on the token associated with the installed certificate. In this case, teh certificate must be installed on the host server of the calling application.

## About STS

A Security Token Service (STS) is a component that issues security tokens and authenticates the identity of the requesting user (or system). In this capacity, STS is the identity provider.

STS operates in accordance with industry standard WS-Trust and WS-Federation protocols under WS-Security specialization. As such, the token service is the issuing, renewing, and validating authority for security tokens and establishes the trust relationship between participants in a secure message exchange.

## Implementation

The implementation involves the use of an open source third-party project that interacts with Windows Identify Foundation (WIF) as an identity-aware application.

The service delegates authentication to the STS by establishing the appropriate references and trusts in the WIF libraries and web configuration files. The WS Federation bindings supporting this functionality are contained in the policy at the service level.