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$