Shibboleth Developers

First off, I'd like to thank Scott Cantor for his help in developing 
these notes.

I've tried to collect together and organize information about the 
various approaches that have been suggested for adding security to 
the two SOAP-based protocols that we're discussing. I suppose there's 
a hope that the approach we agree on would be sufficiently general 
that other applications could also use it.  This note is longer than 
I would have liked, but I've tried to be complete.

If, while reading this note, you develop some issues or concerns,  or 
feel that some important point was inadvertently left out, please 
send  email to the list.

Talk to you at 3 pm edt.

Recent discussions on the Shib-dev conference calls and mailing list 
have been exploring approaches for adding security to SOAP based 
protocols used to access services in the distributed network. We've 
collected use cases from two Projects that export a SOAP interface: 
Fedora, and ECL.
Neither Fedora nor ECL currently have a security model or framework, 
or security component in their protocol messages. Both would like to 
"add security", where Shib is one of several Authn mechanisms these 
projects would like to support. They would also like to negotiate a 
security mechanism  at runtime.

BACKGROUND INFORMATION

Background info on both projects  is included at the end of this note.

Both of these projects are assuming a non-browser program in the 
desktop (ie the heretofore not seen in the wild "SOAP-based client"), 
making a HTTP connection to a remote server. This client would be 
sending SOAP messages, and binding them to HTTP. Both projects have 
existing client programs which would have to be extended to 
accommodate the new security model.

SOAP clients would have very little control over the TCP connection, 
or ability to keep a connection alive.. Most web servers are very 
conservative about keep-alives; SSL servers almost always drop a 
connection after a few seconds. Presumably, both Fedora/ECL want to 
have an application-layer session, while HTTP and SOAP are both 
stateless.

In a typical application scenario, several commands (usually Queries) 
and Responses could be exchanged. Because of this, there is a strong 
incentive to avoid using heavyweight credentials on every command at 
the application layer. The cost of having the server validate an XML 
signature on every message will be prohibitive. Instead, there is a 
strong incentive to explore lightweight approaches -- mechanisms 
which might require substantial processing on the first transaction, 
but where processing on subsequent transactions is much faster and 
lighter.

THE PROPOSED AUTHN MODEL

When the client successfully presented Authn credentials to the 
server, a security context would be established at the server, and 
would remain in place until a logout occurred  (via some currently 
unspecified means), or a second set of Authn credentials were 
presented (ie "now do a login with these"), or the TCP connection was 
terminated.

Presumably, the client would present these Authn credentials 1) 
either at the  start of  the session, or 2) when the server responded 
to some request by saying "authn required".

We've explored two security approaches: WS-Sec ( 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss ) and 
using HTTP-level Authentication. However, these two are not really 
comparable. HTTP basic-auth, or TLS, both feature the complete flow. 
WSS only addresses attaching a token to a message. It is by design 
impossible to use without a higher level profile.

There is currently no "best practice" describing how to add security 
to SOAP  (where "best practice" is derived from actual experience). 
The approach most frequently used at this point is to rely on 
HTTP-level authentication. This is somewhat limiting (eg very few 
mechanisms are specified), but is well understood, and there is lots 
of experience with this approach. TLS is a bit different than HTTP 
authentication, but is often more secure and more well-specified, and 
is the real common case today. Arguably it's all you *should* use if 
the communication is end to end, and the client can support a 
keypair. SAML SSO exists because browser users are deemed incapable 
of this.

HTTP-ASSOCIATED AUTHENTICATION

This seems to be the current best practice. SOAP messages are 
transported using HTTP. The HTTP or SSL/TLS layer is responsible for 
providing authentication. SSL/TLS, if being used, is responsible for 
message integrity and message confidentiality.

Authentication can be done at the SSL/TLS layer if the client has a 
private key and certificate. Authentication would essentially be done 
out-of-band form the SOAP level session. (PKI is the only 
authentication mechanism supported by SSL/TLS.) Web browsers support 
this mechanism, although very few campuses have deployed the PKI 
infrastructure required to make this work. Grid infrastructures use 
short-lifetime certificates which are created after a client presents 
some other valid credential (eg a Kerberos ticket) to a KCA-style 
process. The client would typically authenticate with the user's 
credentials. The server would obtain the user's identify from the 
presented certificate, and would assume that all of the transactions 
should be conducted in the security context created with the user's 
credentials. TLS is effectively lightweight, even if multiple serial 
TCP connections are created to support the SOAP level application 
session. The initial handshake is slow, but the setup of subsequent 
TCP sessions is fast due to caching. An SSL/TLS tunnel would support 
message integrity and message confidentiality, even if SSL/TLS were 
not being used for authentication.

Authentication can also be done at the HTTP layer. Some code in the 
client must recognize the HTTP responses which indicate 
"authentication required" and respond appropriately. Unfortunately, 
HTTP authentication only profiles userid/password. Kerberos is also 
profiled (via SPNEGO), but support for this is not yet widespread.

SAML/Shib style authentication would have to be done using the SAML 
Browser profiles (Artifact or POST). Programming these into a client, 
though, would probably be be a messy business.


WS-SEC, and LIBERTY'S PROFILE OF WS-SEC

The WS-Sec family of standards, which specify how to add security to 
SOAP-based transactions, are very new and haven't yet seen much field 
testing. In addition, the family of specifications haven't yet been 
completed. That's a nice way of saying "the ice is very thin....". 
Liberty has developed a completed set of specifications for SOAP 
based transactions; the Liberty security specification is based on a 
draft of WSS (but not the final version).

The lack of a complete set of standards is a troubling issue. 
Different groups are proposing different approaches to some of the 
outstanding issues..... I think our task  will be  to understand  our 
requirements, and  make the best choice we can... understanding full 
well that three years from now the market may have decided that there 
were better choices than the one we made. And I suspect that some 
people may suggest "this situation is too confusing...let's  wait". 
That's a possible choice, too.

Web Services Security: SOAP Message Security V1.0

(the next four paragraphs have been taken from the WS-Sec spec) This 
specification describes enhancements to SOAP messaging to provide 
message integrity and confidentiality. The specified mechanisms can 
be used to accommodate a wide variety of security models and 
encryption technologies. This specification also provides a 
general-purpose mechanism for associating security tokens with 
message content. No specific type of security token is required, the 
specification is designed to be extensible (i.e.. support multiple 
security token formats). For example, a client might provide one 
format for proof of identity and provide another format for proof 
that they have a particular business certification.

This specification is flexible and is designed to be used as the 
basis for securing Web services within a wide variety of security 
models including PKI, Kerberos, and SSL. Specifically, this 
specification provides support for multiple security token formats, 
multiple trust domains, multiple signature formats, and multiple 
encryption technologies. The token formats and semantics for using 
these are defined in the associated profile documents.

This specification provides three main mechanisms: ability to send 
security tokens as part of a message, message integrity, and message 
confidentiality. These mechanisms by themselves do not provide a 
complete security solution for Web services. Instead, this 
specification is a building block that can be used in conjunction 
with other Web service extensions and higher-level 
application-specific protocols to accommodate a wide variety of 
security models and security technologies.

These mechanisms can be used independently (e.g. to pass a security 
token) or in a tightly coupled manner (e.g. signing and encrypting a 
message or part of a message and providing a security token or token 
path associated with the keys used for signing and encryption)

(this paragraph from Scott) The Liberty WSF security mechanism 
specification (based on a draft of WSS but not the final version) 
supports TLS and WSS with the password, X.509, and SAML profiles. 
They also support using TLS and then passing SAML Holder-of-Key 
tokens without needing a second signature to prove ownership. The 
SOAP binding specification has the stuff about message correlation 
and I believe also the session context stuff. Jeff's SASL stuff is in 
separate doc. Liberty also has a client profiles spec for things 
called LUADs, which are basically SOAP clients, that builds on the 
other specs and is probably relevant.

There are a some problems with adopting WS-Sec, tho, resulting from 
the relative immaturity of this family of protocols:

1) There is currently no standard within the WSS family defining the 
relationship between a presented set of security credentials and a 
specific session, and a mechanism for referring to that session in 
future message exchanges. There are, in fact, two camps espousing 
different approaches to this problem, and they begin to differ at the 
session level (eg handling the session cookie). WS-Sec relies on the 
"still  cooking" WS-ReliableMessaging and Secure-Conversation 
specifications for this functionality. This relationship is a 
particular issue if there are multiple sessions within a single TCP 
stream. There are some rather obvious ways to establish this 
relationship. Liberty has addess these holes; the Liberty ID-WSF SOAP 
Binding has the SessionContext header for just this purpose.

2) A shib-only problem -- In the SAML family of specifications, the 
only existing profiles are the browser ones -- there are no profiles 
describing how a SOAP client obtains a SAML credential and then 
proves that the credential refers to the person using the client. 
Again, there are some obvious ways to do this (ie HoK), but there is 
currently no promulgated standard.

However, any decision choosing an  approach on either of these issues 
will likely have to be  revisited in 2-3 years, when the appropriate 
standards are in place.

3) Another concern is the availability of open source code 
implementing WS-Sec. There is an apache projects that looks to be 
quite active...... http://ws.apache.org/ws-fx/wss4j/

The real hard work, tho, is in the mechanism specific plugins, which 
have to develop and interpret the tokens.

There was an IPR issue with a previous apache project in this area.

Big Questions for the Projects:

1) Is there any "interoperability" requirement here? Are they 
supporting a "standard" on-the-wire protocol, and are there other 
implementations of that protocol that the projects would like to 
interoperate with? Should we talk to those projects about their 
security requirements?

2) Where is the risk, the exposure of defining our own approaches? Is 
that risk acceptable (compared to waiting for the standards bodies to 
act)?

3) How would a server indicate, midway thru a series of requests, 
that the client must present security credentials in order for the 
server to process the previous request? (presuming the client will 
have to resubmit the request accompanied by credentials) This is a 
key issue, and a lot of the specs are vague on it. (From Scott: In 
Liberty, I think the idea is to return a SOAP fault, but we can check 
on this.)

4): SOAP doesn't assume HTTP... do Fedora/ECL?

THE OPTIONS IDENTIFIED SO FAR:

1) SSL/TLS Authn. issues include where would the client get the cert; 
how to support SMAML/SHIB.

2) HTTP-Level-Authn: issues include how to support Kerberos and 
SAML/Shib mechanisms.

3) vanilla WSS: issues include: protocol definitions not complete, 
we'd have to make some decisions to fill in the gaps.

4) Liberty with WSS: issues include: specifications are complete, and 
are being implemented. Is this a route we want to follow?

------------------------------- BACKGROUND INFO

Fedora is a digital repository;  info is available here: 
http://www.fedora.info/ .

Also, we have a list of the usage scenarios for which we want to provide
authentication:
http://www.fedora.info/wiki/bin/view/Fedora/AuthNAuthZScenarios.  We'll be
fleshing this out, but the basic cases are listed for now.

Also, the page where our work-in-progress notes for security are posted is
at:
http://www.fedora.info/wiki/bin/view/Fedora/DesignInProgress

------

ECL is a SOAP-based implementation of the IMS DRI protocol. Info is 
available here:

        http://www.edusplash.net/technical/ecl/index.html

ECL is provided as as a "connector". A client or server can use the 
comparatively simple API of the connector, and thus be shielded from 
the complexities of understanding the ECL protocol  itself. There are 
several examples of existing repositories developing support for 
using the ECL connector.

ECL use cases... client looks in the registry, identifies one or more 
repositories for use in searching, client sends queries directly to 
each of the repositories  (ie no federated searching).

Also the gateway use case (the gateway maps from ECL to other search 
protocols)... deferred for now

-- security context maintained by the connector, or known to  application?