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