Article:		Web Services Security, Part 1
Subject:		false sense of insecurity: Axis Developer's response
Date:		2003-03-21 13:02:15
From:		Steve Loughran
Response to: false sense of insecurity: Author's response
I celebrate disagreement; it introduces new ideas. This is why, sadly, I must continue to disagree with your statements. The key issue I have is that you are talking about SOAP over HTTP, yet using only the SOAP specifications for information, when you should be using the HTTP specs as well. Your question was" "We have two web services hosted on the same SOAP server. I want to allow user A to access web service 1 but not web service 2. I want to allow user B to access web service 2 but not web service 1. How will I stop user A from accessing web service 2, once his IP address has been authenticated and authorized? " This is trivial. Really. It is so trivial it hurts. Imagine we are running a server with web service 1. Because in SOAP over HTTP, services are bound to endpoint URLs, this service has an Url that defnes the service : http://example.com/axis/services/Service1 now lets add another service. It will have its own endpoint: http://example.com/axis/services/Service2 Can you see where I am getting at yet? If I want to let user A at service 1, and user B at service 2, then all I have to do is configure the web server that is hosting the Axis runtime so that the URLs have different security rights. That's all. Router side, I could do this by fiddling with arrowpoint security settings to restrict by IP address. But we want authentication, rather than just IPaddr filtering so what do we do? We go to the servlet API spec and look up what it takes to add security to a pattern of URLs, and extend the web.xml of Axis to filter on URLs: <security-constraint> <web-resource-collection> <web-resource-name>Service1</web-resource-name> <url-pattern>/services/service1</url-pattern> </web-resource-collection> <auth-constraint> <role-name>service1</role-name> </auth-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Service2</web-resource-name> <url-pattern>/services/service2</url-pattern> </web-resource-collection> <auth-constraint> <role-name>service2</role-name> </auth-constraint> </security-constraint> Now when anything hits service1 it gets a 401 response, "no auth", and has to respond with the authentication information before it gets through. With the appropriate configuration of the app server, such as this change to tomcat's server.xml: <tomcat-users> <user name="userA" password="userA" roles="service1" /> <user name="userB" password="userB" roles="service2" /> </tomcat-users> we get an app server that only gives userB access to the service2 role, and userA access to the service1 role -and our services have their access restricted to the roles of the same name. Thus the HTTP infrastructure that SOAP is running over is preventing anything from POSTing to the different endpoints. Therefore I rest my case: you do not need extra security above and beyond HTTP (digest) and HTTPS to have encrypted and authenticated SOAP messaging over HTTP. I am not doing any "tricks that destroy interoperability" as you claimed. We, and by that I mean everyone who implements SOAP over HTTP client and server frameworks, are reusing the existing pieces of the HTTP infrastructure to offer people security they can understand. The rationale for WS-security is not that HTTP security is inadequate; it is because some people want to move beyond HTTP as a transport. Once you change transports you have a different problem. But your 'figure 7' service is quite clearly an HTTP based solution, which you can secure quite easily today. Like I said before: don't panic so much. -steve http://iseran.com/Steve

Previous Message

Up

Next Message

• false sense of insecurity: Author's response
  2003-03-30 23:22:21 Bilal Siddiqui
  
  You can continue disagreeing without going sad. We can do it happily as it introdcues new ideas!!!

  
  However, I do not find much of a disagreement in your message. Your first message was about little security tricks (user tokens, IP addresses etc. for authentication) and I explained that we have to work with standards, without which we cannot ensure interoperability. For example, if we decide about user tokens, we need standards describing how to wrap and process security tokens in XML format.

  
  At the end of my last message, I just put up a question, in which I was trying to prove that user tokens inside SOAP messages (the XML layer) are necessary for web services security. We cannot use lower layers for web services security.

  
  After reading your latest message in which you want to celebrate further disagreement, without commenting anything on the main issue of the first message (interoperability), I think there is a basic confusion about two things. Please note that *interoperabiulity* and *deciding the level to implement web services security* are two distinct problems. You have chosen to disagree
  only about the level to implement web services security. So I think the interoperability debate is over, with a conclusion that we have to stick
  with standards. However, you can reopen the debate any time, happily :)

  
  Your answer to my question assumes that my question was specifically about SOAP over HTTP, while my question did not mention SOAP over HTTP. However, I do think I should have explicitlly mentioned in my question that I am talking about SOAP in general and not SOAP over HTTP. So, let's discuss BOTH cases: SOAP in general AND SOAP over HTTP. And you will see that using HTTP end points to implement web services security is inadequate in both cases.

  
  You mention "The rationale for WS-security is not that HTTP security is inadequate". Did I ever say that HTTP security is inadequate? My point is that HTTP security is not suitable for SOAP (and this is *partly* the rationale for WS-Security). Let's consider two of the popular models for moving beyond HTTP as a transport:

  
  Messaging middleware applications like JMS
  Virtual network overlay applications like JXTA

  
  In both these applications, there will be middleware modules working effectively as routers over HTTP or some other equivalent transport. Such middleware modules give rise to the concept of SOAP intermediaries. The simple result is that the SOAP requester and the ultimate recepient of the SOAP message (the SOAP server which is supposed to author the SOAP response) MAY not know the HTTP or IP addresses of each other. So you cannot rely on web service end points to implement security. And if you do rely on web service end points, I think here you are breaking the well established rules formed in the early days of OSI stack development, when people used to argue what functionality should be built into which layer. Resuability (abstraction and encapsulation) are proven techniques not just in OO, but also in protocol stack development.

  
  And if you trivialize this matter today, you will need to re-build systems as business logic grows.

  
  Another thing. If we do consider SOAP oever HTTP, how will you implement operation or method level authorization policies?

  
  These are the reasons, I don't consider HTTP for securing web services. And I think SOAP developers also appreciate these points. Please go through section 7.1.2 of SOAP Version 1.2 Part 2: Adjuncts specification. This section describes the *purpose* of SOAP HTTP binding. For your convenience, here is an extract from the official document:

  
  QUOTE:
  This binding is not intended to fully exploit the features of HTTP, but rather to use HTTP specifically for the purpose of communicating with other SOAP nodes implementing the same binding. Therefore..........
  UNQUOTE:

  
  I think, if you rely on HTTP for anything other than "specifically for the purpose of communicating with other SOAP nodes", you are misusing the technological framework available. Your customers will pay the price later on for this over-trivialization. And you see, that's why it hurts!

  
  I mentioned in the begininng "I do not find much of a disagreement in your message". I think the only disagreement is in the "frame of minds". You solve a problem without considering what's coming next and say "Look this is so easy that it hurts". And I am trying to focus on what's coming next, and therefore don't think that your solution addresses the problem at all.

  
  Your further disagreement is most welcome.

  
  Bilal

  
  
  
  
  

  • false sense of insecurity: Author's response
    2005-09-26 11:43:58 tony!
    
    First: I wanted to say I have really enjoyed this article and the banter at the bottom.

    
    Second: I wanted to throw in my two cents.

    
    I agree with both of you but I have found a recent need to not follow the standards when it comes to developing secure web services.

    
    By monitoring the raw structure of a SOAP request and return message it is clear that SOAP is simply a hybrid of the HTTP message structure.

    
    For example:

    
    *HTTP*
    ---Standard HTTP header POST (non-soap post):
    POST /ReportService/Publisher/createReport HTTP/1.1
    Host: somehost.com
    Content-Type: application/x-www-form-urlencoded
    Content-Length: length
    Followed by standard HTTP post data

    
    ---Standard HTTP header RETURN
    HTTP/1.1 200 OK
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    Followed by XML

    
    *SOAP*
    ---Standard SOAP header POST:
    POST /ReportService/Publisher HTTP/1.1
    Host: somehost.com
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    SOAPAction: http://somehost.com/ReportService/createReport
    Followed by XML

    
    ---Standard SOAP header RETURN
    HTTP/1.1 200 OK
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    Followed by XML

    
    
    As you can see, in these examples, the posting/request headers are nearly identical and the return headers for HTTP and SOAP… ARE identical.

    
    Beyond the header you either process XML or HTTP post data which is nothing more than “string” or “string encoded” data unless it has a binary attachment.
    Any hacker will find this easy to strip apart and analyze then later mimic a valid consumer.

    
    First habit: Always use SSL. You really don’t need another layer of encryption beyond this. Though in some cases I do anyway to provide an additional layer of security but it is really not needed other than to provide comfort to a customer.

    
    Second habit: Minimize how often the client consumer has to send authentication. I only have a consumer send authentication once and authentication can only happen through a “connection” web service method. I then create a “session token” (or GUID) on the service side and return it to the client. The client then HAS to keep this “session token” and included it with all subsequent web services calls.

    
    Yes… these habits require that I run my own “session” manager on the service.

    
    I use this custom session manager to link to our roles and permissions settings to quickly determine if a calling user has access to the method AND/OR the CONTENT/DATA the method may return. In some instances the user will have access to a method but not the selected content that the method can request for. (This is key... security really goes beyond access to a web service method but also to the data that a method can return... just because a client has access to a method does not mean they have access to ALL data that method can return.)

    
    The “session” manager monitors for these issues and modifies the returned XML to inform the consumer that they don’t have access to that data.

    
    I try to never return a 404 error. I always try to return an XML result that provides some status like…
    <STATUS>
    <ERROR>FAIL<ERROR>
    <MESSAGE>You are not authorized.</MESSAGE>
    </STATUS>

    
    To prevent a ‘stolen session’ you simply monitor the calling IP. If the calling IP does not match the IP originally associated with the “session token” when it was created then that call fails. If you don’t have access to the calling IP (or if you don’t have access to the protocol layer) you are in trouble and should resolve this issue first because you will not be able to properly monitor and/or provide secure web services.

    
    The above methodology (beyond the SSL) allows for providing a “proprietary” token and XML authentication structure to and from our services to further prevent “most” hacker attacks. This also removes much of the “overhead” and reduces the size of the SOAP data to better support poor bandwidth environments. (Yes… poor bandwidth environments still exist… most of my experience with web services is in support of getting data to our troops in Iraq which include networks just vanishing and passing through 20 year old satellite technology. HTTP/SOAP does not guarantee message delivery (return stream) in these environments. (...another story for another time…))

    
    This is all probably an over simplification and I look forward to holes and examples to problems with the above theory.