Security Considerations

[Stephen.Flinter@connectcgs.com]

All,

this email followis on from my action to consider some of the security
options that we have with respect to the Translation Web Service standard.

Security Options

There are four major options that we have, as far as I can see:

1. Do nothing
2. Pick a standard and specify its full adoption
3. Pick a standard and specify the adoption a small part of it
4. Specify our own security fuctionality

1. Do Nothing

This option is by far the easiest.  We would avoid making any references to
any security standards, and leave that entirely up to service provider to
specify what security architecture/standards/protocols that they provide.
It would then be responsibility of the service client to implement the
relevant functionality to comply with the security offered by the service
provider.

The advantage of this approach from a specification view point is that
there is nothing to do - security becomes an implementation detail.  A
second advantage is that we don't tie the hands of those implementing the
WS-Translation standard - they are free to choose the most appropriate
level and type of security for their application.

The disadvantage of this approach is that everybody will end up with a
different security implementation, and hence, a client application of one
service provider will not necessarily work with another service provider.
It will be necessary to develop additional functionality to work with the
security protocols of each additional service provider that a client wishes
to communicate with.

2. Full Adoption of a Standard

This option would involve picking an appropriate standard - probably either
WS-Security or SAML - and mandating that an implementation of the
WS-Translation also provides for a full implementation of the security
standard.

The advantage of this approach is that the specification is fairly
straightforward.  We examing the various standards that are available, and
choose one that is closest to what we want to do, and mandate that this
standard be implemented.  A secondary advantage is that there would be one
and only one security standard in play, and hence, a WS client for one
service provider will work with all other service providers (assuming that
they implement the security standard fully and correctly).

The biggest disadvantage is that we are placing a significant burden on
those implementing the WS-Translation standard.  Not alone do they have to
fully comply with WS-Translation, they also have to comply with a second
stardard, and put the security architecture demanded by that standard in
place.  This may be overkill for the first version of the standard.

3. Partial Adoption of a Standard

This option involves picking an appropriate standard - again either
WS-Security or SAML - and specifying that a small and relevant part of that
standard must be implemented by the service provider, and by the WS
clients.

For example, the following is an extract from the WS-Security standard that
may be appropriate:

      <wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
            <wsse:UserNameToken>
                  <wsse:Username>Joe</wsse:Username>
                  <wsse:Password>password</wsse:Password>
            </wsse:UserNameToken>
      </wsse:Security>

Here, the username & password are send in an XML fragment in the SOAP
envelope.  Since the password is send in plaintext, the SOAP converstation
would have to take place over an encrypted connection - e.g. HTTPS.

In addition to mandating the implementation of a partial security standard,
we could also leave the door open for a more complete implementation of
that standard, in the event that a service provider felt that it was
necessary or appropriate.

The advantage of this approach is that we would have some security in our
specification, without over-burdening those implementing the standard.  In
addition, we would leave ourselves the option of including additional
security measures in later versions of WS-Translation - moving over time
towards option 2 above.

The disadvantage of this approach is that the piece of the security
standard that we choose will not be acceptable to all service providers,
and hence, they may end up moving in different directions (as described in
option 1 above), and hence, leading to incompatible implementations.

4. Specify our own Security

The option would involve specifying whatever security options that we think
are relevant for WS-Translation.  It may involve ignoring, or at least not
being bound by, existing standards out there, and going it alone.

The advantage of this approach is that we can specify exactly what we want
(e.g. authentication, authorisation, encryption, etc.), and ensure that it
is implemented in a standard way.

The disadvantage of the approach is that we would be ignoring work that has
already been done in this area, and possibly by-passing other security
infrastructure that a service provider or client may have.

Summary

In summary, and as a personal bias, I feel that we should:
1. Provide at least enough security specification to allow user
authentication - that is validating that a user is who they say that they
are
2. The implementation path for this authentication service should be fairly
straightforward
3. We should leave the door open to implementors to expand on the security
offered, in the event that their application or domain demands it.
4. We should leave the door open to ourselves to add additional security
requirements in the specification at a later date.

I feel that option 3 above best meets these goals.  Whether the fragment of
the WS-Security standard that I showed above is the right one to choose or
not is another debate, but it does appear to meet the authentication
requirements - albeit over HTTPS.

Appendix

There are (at least) two relevant standards in the security realm that we
need to consider:

1. WS-Security:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
2. SAML (Security Assertion Markup Language):
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

In addition, there is a new OASIS group Web Application Security:

3. WAS: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=was

Of these, SAML appears to be the most active.  However, additional research
time will be required to identify which of these standards is most
appropriate for our needs.

---------------------------------------------
Stephen Flinter
Connect Global Solutions
[t] +353 (0)1 882 9038
[f] +353 (0)1 882 9050
[m] +353 87 798 1228
[e] stephen.flinter@connectcgs.com
[w] www.connectcgs.com
--------------------------------------------