Introduction to STS
The Security Token Service (STS) lets AM bridge identities across existing federated environments to establish cross-domain trust relationships using token transformations. For example, you can federate two different environments by transforming OIDC ID tokens into SAML v2.0 assertions.
To do this, AM provides a REST STS framework for token transformations. This framework is loosely based on the SOAP WS-Trust specification.
A WS-Trust model involves communication between the components, a requestor, web service, and the STS:
-
The requestor is a web client or programmatic agent that wants to use a service offered by the web service.
-
The web service lets authenticated and authorized clients access resources or applications.
-
The identity provider stores claims about subjects and works with the STS to issue security tokens.
-
The STS acts as a trusted third-party web service. It asserts the identity of a requestor across different security domains through the exchange of security tokens and brokers a trust relationship between the requestor and the web service provider. The STS issues tokens based on its configurations, which model the identity of a given identity provider, and issues tokens to a specific relying party.
-
A security token is an STS data structure representing a set of claims that assert the identity of a subject. A single claim is identity information, such as a subject’s name, age, gender, and email address.
Web services and requestors (that is, consumers or clients) are typically deployed across different security domains and topologies. Each domain may require a specific security token type to assert authenticated identities. The STS provides a way to exchange tokens across these different domains without re-authenticating or re-establishing trust relationships while allowing the requestor access to a web service’s protected resources.
Supported features
The STS supports the following features:
- REST endpoints
-
REST endpoints are exposed upon instance creation.
- Token transformations
-
The STS issues OpenID Connect V1.0 (OIDC) and SAML V2.0 tokens (bearer, holder-of-key, sender vouches).
- OIDC
-
Username token → OIDC
OIDC → OIDC
X.509 token → OIDC
AM Session token → OIDC - SAML V2.0
-
Username token → SAML v2.0
X.509 token → SAML v2.0
OIDC token → SAML v2.0
AM Session token → SAML v2.0
- Publish service
-
You can configure STS instances using the AM admin UI or programmatically. AM provides an STS publish service that lets you publish these instances with a POST request to the endpoints. Because a published instance can have only a single encryption key, you need one published instance per service provider that the web service invoking the STS intends to call.
- Custom SAML assertion plugins
-
AM supports customizable SAML assertion statements. You can create custom plug-ins for
Conditions,Subject,AuthenticationStatements,AttributeStatements, andAuthorizationDecisionStatementsstatements. - Custom token validators and providers
-
The STS provides the ability to customize tokens. For example, you can configure STS to transform a token of type CUSTOM to a SAML V2.0 token.