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 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.
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.
Via a set of assertions, a security policy describes how a web service expects its messages to be secured. This set includes:
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.
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.
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.
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.
To exchange metadata such as WS-SecurityPolicy policies, we need to implement WS-MetadataExchange. References are to the September 2004 draft.
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.
Last updated: $Id: roadmap.html 239244 2005-08-22 20:37:08Z dims $