This article continues from the previous one for claim provisioning and is dedicated towards security token service.

A security token service can relieve this end-to-end workflow by performing authentication for clients including services and users and providing security tokens for clients to present to the applications. It can support authentication federation for passive clients as well as a trust protocol for the active clients. It can implement a variety of authentication and authorization protocols including OpenID and OAuth while remaining aligned with enterprise authentication guidelines. It can provide a control plane for other services to integrate, and this plane can be internal without any risk of allowing customer access to identity providers. It can be provided regionally for application affinity and for isolated deployments. It can feature in an organization’s service inventory and leverage it for interacting with other services.

One of the instances of the Security Token Service can be used to support dialtone service requests. This follows the same routine as any other Security Token Service instances but with the dedicated purpose of providing dialtone response to other services. Any application using this service must support the right affinity to the dialtone instance. A dialtone service is a self-contained instance with a backup that is running on an infrastructure separate from that of others.

A dialtone service contributes towards resiliency. The local authentication supports cached security group memberships to provide continuity of DevOps account authentication if the Active Directory is not available. In such a case, the client manually selects the local dsts authentication option when requesting a security token.

The issuing authority for a security token does not have to be of the same type as the consumer. Domain controllers issue Kerberos tickets and X.509 certificate authorities issue chained certificates. A token that contains claims is issued by a web application or web service that is dedicated to this purpose. This plays a significant role in the identity solution.

Failover for active clients is achieved automatically if the authentication client is making simultaneous token request calls to both the primary and backup instances, with a preference based on the waittime  for the primary. Passive clients can achieve this using a manager which detects that the primary issuance endpoint is unavailable and routes traffic to the backup within half a minute.

The relying parties are the claim-aware applications and the claims-based applications. These can also be web applications and services, but they are usually different from the issuing authorities. When it gets a token, the relying parties extract claims from the tokens to perform specific identity related tasks

Interoperability between issuing authorities and relying parties is maintained by a set of industry standards. A policy for the interchange is retrieved with the help of a metadata exchange and the policy itself is structured. Sample standards include Security Assertion Markup Language which is an industry recognized XML vocabulary to represent claims. 

A claim to token conversion service is common to an identity foundation. It extracts the user principal name as a claim from heterogeneous devices, applications and services and generates an impersonation token granting user level access to those entities.