Apache TSIK roadmap

This is a proposed roadmap for The Apache TSIK project. Please send feedback to <tsik-dev@ws.apache.org>

Initially, there is room for both WSS4J and TSIK since they serve somewhat different target audiences. Over time, depending on the desire of TSIK developers, TSIK XML security layers may be re-architected to use Apache XML-Security libraries. WSS4J and TSIK may also assimilate into a single project using the best parts of both.

Some of the initial ideas of TSIK is to implement WS-* standards as they are developed, in particular the ones related to implementation of a federated ID protocol such as Microsoft's InfoCard. (There are other federated ID protocols, for example, Liberty Alliance, Sxip networks, Identity Commons, LID NetMesh, Passel.org, but only InfoCard seems to be based on open web services standards.)

InfoCard

InfoCard is a web services based federated identity model proposed by Microsoft in Microsoft's vision for an Identity Metasystem and further described in the downloads of the WinFX runtime components Beta 1.

The idea behind InfoCard is to build and depend on a number of freely available WS-* standards. The main components are WS-Trust, WS-SecurityPolicy, WS-MetadataExchange, but there several other standards used to some extent.

With its dependance on WS-* standards, InfoCard fits well into the original proposed scope of TSIK implementing WS-* specifications related to security.

Limitations

Microsoft's vision of an identity system ties into the operating system. The idea is to embed the InfoCard engine into a sandbox within the OS to avoid many types of rouge attacks. One way of picturing how InfoCard will look on the OS level is to compare it to the limited login sandbox (that is, what you get when you CTRL+ALT+DEL on a Windows XP box). The user will select her InfoCards within this protected environment.

Obviously, Apache TSIK doesn't operate on the OS level, so that is a limitation on what Apache TSIK can accomplish. There are several other limitations as per specifications as outlined below.

Components

There are a few concepts in InfoCard that are important to point out.

Security policies

Via a set of assertions, a security policy describes how a web service expects its messages to be secured. This set includes:

protection assertions to describe what parts of a message are secured,
conditional assertions to describe general aspects or pre-conditions of the message security,
security binding assertions to describe the security mechanism in use,
supporting tokens assertions to represent token types and usage patterns for additional claims, and
WSS and trust assertions for trust options when referencing tokens.

In the InfoCard system, both the identity providers and the relying parties (see the link above for definitions) define security policies. Security policies are communicated via WS-SecurityPolicy and exchanged via WS-MetadataExchange.

Infocards

The Infocard itself represents an identity. Together with the Infocard runtime system, the user selects an infocard that fits into the various security policies in place.

Security token

A security token represents a collection of claims about an entity. Typically, this token is used to authenticate the sender or responder in a message transaction. Types of tokens include X.509 certificates, Kerberos tickets, SAML assertions, etc., and also simpler constructs such as username/password). Parties exchange security tokens via WS-Trust.

Roadmap

The order in which standards need to be implemented is fairly straight-forward. In this section we describe that order and also which portions of each standard can be deferred until later. Once specific interop scenarios become available, the implementation should set such interop as highest priority.

WS-MetadataExchange

To exchange metadata such as WS-SecurityPolicy policies, we need to implement WS-MetadataExchange. References are to the September 2004 draft.

Both metadata reference and location should be supported. (3.1)
Neither WSDL definitions, nor XML schema metadata dialects are not supported, only WS-Policy. (3.1)
WS-Addressing headers must not be used. (3.2)

WS-SecurityPolicy

Ws-SecurityPolicy is a thorough specification and it is necessary to limit its implementation to the highest degree possible. This will be easier to accomplish, of course, once interop scenarios become prevalent. In the meanwhile, here are some suggested limitations. References are to the July 2005 draft.

To mimimize workload, use of WS-Policy and WS-PolicyAttachment specific details must be kept to a minimum. (Specifically section 4, but throughout)
Nested policies are not permitted. This avoids issues with normalization and intersections. (4.1)
WSS 1.1 dependencies are not permitted, only WSS 1.0 (Throughout)
WS-SecureConversation derived keys are not permitted. (6.2.1)
Only UsernameToken and X509 assertions (using X.509 v3 certs) are permitted (6.3.*)
Only TripleDesRsa15 algorithm suite is supported. This is a temporary constraint only, depending on existing TSIK source. (7.1)
Only the Lax Security Header Layout property is allowed (7.7)
TransportBinding (8.3) and SymmetricBinding (8.4) assertions are not allowed, only AssymetricBinding (8.5) assertions.
Only supporting tokens defined by (9.1) are allowed. No other supporting tokens in section 9 are permitted.
For WSS 1.0 properties (10) all references are permitted.

Still under consideration is:

WS-Trust assertions defined in (11).

WS-Trust

To be discussed.

Unknowns

SAML status with ASF. For potential future use, consider http://www.opensaml.org

Main Apache TSIK page.

Last updated: $Id$