Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
STS IdP
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
The Higgins Security Token Service (STS) IdP Solution is an extensible and adaptable framework that implements the OASIS WS-Trust standard and provides support for deployment in a variety of scenarios. It creates relying party consumable Digital Identities from Claim data.
Note: In the Higgins project we sometimes use the term "Token Service" instead of the commonly used STS (Security Token Service) term.
Contents
Version
This page describes the STS IdP Solution that was released as part of Higgins 1.0 as well as the version of this solution that will be part of Higgins 1.1
End-User Perspective
A running instance of this deployment is available here: https://higgins.eclipse.org/TokenService/index.html
Deployer Perspective
Download
Download and unzip the war.zip file for the built web application from one of the builds from here
Deploying
Configuration
Developer Perspective
Architecture
Claim data can either be "pushed" (passed) in by client code (e.g. I-Card Provider) to the STS and passed in turn to a Token Provider, or the STS can "pull" (retreive) claim data from the I-Card Provider.
The framework consists of:
- a Java implementation of the core engine component along with a set of Java interfaces that describe plug points for components,
- a set of Java implementations of platform specific bindings (e.g. Axis 1.x),
- a set of Java implementations of security token extensions (e.g. SAML 1.1), and
- a web application that faciliates the registration and management of digital subject profiles.
The framework is also dependent on the Higgins Identity Attribute Service (IdAS) and one or more Context Providers (CPs).
The core engine component is configurable through an API; typically invoked by a binding component implementation. The core engine is responsible for loading and configuring security token extensions and Context Providers (Context Providers are registered in the IdAS Registry). When Request Security Token (RST) messages are received, the core engine retrieves a digital subject from a CP via the IdAS, invokes the appropriate security token extension, and returns the RST Response (RSTR). Note that current implementation limitations have caused the reponsibility for retrieval of digital subjects into the token extensions.
Binding components are responsible for loading and configuring the core engine, accepting messages containing RSTs (via SOAP or some other means), performing platform specific processing on inbound messages (e.g. WS-Security, WS-SecurityPolicy, WS-Addressing), converting received messages into a platform independent representation (STSRequest), invoking the core engine to process requests, converting platform independent responses (STSResponse) into platform dependent representation, performing platform specific processing on outbound responses, and returning response messages to the requestor. Note that some applications may directly invoke the core engine, essentially providing their own binding.
Token extensions consist of handler classes that are configurable through an API; typically invoked by the core engine during its own configuration. Token extensions are responsible for processing received STSRequest messages and generating STSResponse messages. In most cases the core engine can decide which extension should handle which message via its configuration. However, in some cases the core may not be able to determin which handler shoud process a message, and handlers may be polled in sequence to determine which should handle a message.
The digital subject profile management web application is intended to provide a CP independent way to manage user profiles. User profiles can be created, modified (e.g. adding/removing identity attributes), and deleted. Additionally, Microsoft CardSpace compatible Information Card may be generated which associates a digital subject on a deployed STS instance with a credential (e.g. username/password, self-signed SAML Assertion).
All of the above components are provided as part of a reference implementation, any of these components can be replaced by an alternative implementation as long as it implements the appropriate interfaces and operational semantics. This reference implementation is evolving to enable new capabilities and deployment scenarios.
Here is an older architecture diagram: