[Nsi-wg] Presentations from today

[Henrik Thostrup Jensen]

Hi Mathieu

On Wed, 20 Jun 2012, Mathieu Lemay wrote:

> Also, HTTPS is not a transport protocol, but lets get moving.
> 
> Using Transport-Level Security (TLS) is often sufficient if messages are point to point.

This is correct. However peoples definition of "point" seems to vary a 
lot. Is it the same process, same user on a box, same box, same rack, same 
data center, same company?

> Where WS-Security is very useful is when messages are handled by 3rd 
> parties and we want to keep the content private. An example for this 
> would be NSA relays where a message would be forwarded on behalf of 
> another NSA. I'll let you guys judge if it's a required features 
> personally I don't think it would happen often.  

Yes if we need to relay/proxy messages you need some signing of the actual 
data and not just the challenge-response signing of TLS.

However once you go down the road of relaying messages things become odd. 
E.g., Lets say A makes a request to B, which then forwards the message to 
C. Now, there is trust between A and B, and B and C. However for this to 
work, C also needs to trust A. This brings the system into a position 
where everyone has to trust everyone, which is unrealistic. We have also 
agreed in the NSI group that this is not what we wanted (both the thrust 
and message forwarding).

>       Saying that WS-Security is the only option is simple not true.
> 
> For SOAP it's pretty much the only one that survived that plays well with the stacks, But you can always
> have a security proxy in front of the service doing the handshake (OAuth, SAML ECP, etc.) and not care
> about message security.

If one insist that things have to be done in SOAP there aren't that many 
options. However transport-level security have been working quite well 
since 1996 (SSL 3.0) for many applications.

>       SAML? Seriously? :-). Why do we need federated authentication?
> 
> Here I must ask the same question, why federated authentication?  It depends on the level of traceability
> we want to achieve with the users. If it is domain to domain delegation and it's the NSA that is acting on
> the end user's behalf I don't think it's needed however if every domain want to track the end user and
> apply policies in this regard federated identity is desirable.

I agree. However the user only authenticates to one NSA where from the 
identity is carried forward in the message. How the authN is done is 
irrelevant for the NSI spec. (at least we agreed on this in Oxford).

>       It is my impression that SAML is largely being superseeded by OAuth 2.0 these days (which is
>       quite different from OAuth 1 btw.).
> 
> This is mainly do to the fact that REST and simpler interfaces are getting more traction (on that when can
> we expect a REST API for NSI ;) ) they are easier for developers and have less dependencies on the
> libraries and SOAP stacks.

You are preaching to the choir :-). I agree with you on it being easier, 
especially for clients.

> OAuth 2.0 adds what was needed for federated identity and is a lot nicer 
> than 1.0. I use both OAuth and SAML from a middleware perspective and I 
> don't see them as "competing solutions". SAML will give you assertions 
> on which you apply policies whereas OAuth provides federated login with 
> "delegate" access to resources.

Right.

>       WS-Security does not establish a secure transport. That is a very fundemental part of message
>       level security. FWIW there is actually WS standard for establishing secure transports with
>       SOAP called WS-SecureConversation, but I don't want to give you too many good ideas.
> 
> Ideas or nightmares.. ;) WS-SecureConversation was indeed used for the TLS handshake and was used quite a
> bit by GT4 back in the days. Not many people use it these days, they simply use HTTPS with proper certs
> like the rest of the web.

Ah, globus toolkit 3/4. I still cringe when I hear it :-) (I was once 
given the task of maintaining and continuing development of a GT3 
application, but ended up rewriting 40K lines of Java code into 1.5K 
Python, though Globus and not Java was at fault there).

> On a final note I agree with both the slides and Henrik comments and think it is merely a matter of
> perspective however my only recommendation is to keep it as simple as possible and "less is more". Meaning
> that I would rather sacrifice flexibility and I am unsure if WS-Security is really the best option for
> NSI's purpose but because it's SOAP-Aligned (at least for now) I think WS-Security would be the simplest
> to implement.
> 
> A final note, in the past I've had issues between SOAP security stacks, (rampart, cxf, twisted, etc. )
>  between java stacks and the "p languages perl/python/php) mainly because of small differences in the
> implementation. but my main reason for replying comes to this:
> 
> If doing point-to-point communications message-level security is overkill and useless. If messages are
> routed than it's required and  WS-Security is IMO still the best way to go..


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet