SOA and Custom Security Requirements - WSE 3? RRS feed

  • Question

  • Hi,

    I have a couple of custom SOA security requirements that we have implemented using non-WSE approaches. The main reason being that it wasnt obvious to me where (or if) in the WSE 3 based architecture guide for SOA security from MS these requirements were addresses - I was hoping for some suggestions and/or guidence as to the approach.

    Initial Authentication and Authorisation

    The requirement is for a windows client needing to initially authenticate using Windows Authentication to an ASP.NET web-service which is used as a central authentication service. We are using vanilla settings using default credentails to call the web-service which has integrated auth turned on in IIS and 'windows' auth in web.config.

    The client authenticates via the web-service which then retrieves custom authorisation information (roles and some other information from a custom role provider) and returns to the windows client where a generic principal is created so we can take advantage of IsInRole and PrincipalPermission checks in the client application.

    This all appears to work fine.

    Subsequent Application Web-Service Requests

    New web-service requests (for the now authenticated user) from the application back to the server require the passing of some additional information to the web-service as well as credentials. We are currently using the SOAP Header with HttpModule method to allow us to pass username, password and the additional information. IIS is set to anonymous and web.config authentication set to 'None'.

    Likewise this all appears to work fine.

    note : we are using transport (HTTPS) to secure all our communications from client to server.


    I couldnt find anywhere in the WSE 3 Architecture guide where the turnkey approaches supported windows authentication i.e. default credentials and windows authentication turned on in IIS.  Is there a way of doing this with WSE 3 outlined in the architecture recommendations?


    In addition is there a way in the WSE 3 of sharing the custom principal across the client and the server ie. what we are doing by passing information in a soap header (as described above). Once again nothing 'jumped out at me' on how to do this using the WSE 3 architecture guidence. I did some testing with a custom token manager and it appeared you could only pass username and password, not additional information.

    Any responses are most appreciated.



    Wednesday, January 3, 2007 10:58 PM

All replies

  • I wish I knew WSE 3.0 enough to better help you.  On Q1, if you create a security token service (STS) that has IIS/Windows integrated authentication enabled, then your can use the HTTPContext to know that the caller has authenticated against a valid domain account.  The problem is that there is no easy-to-extend STS sample included in the WSE SDK.  If you can get an STS actually working, you then use the security token in the SOAP header, which solves your Q2.  It would be nice if Microsoft delivered a turnkey solution for your scenario -- it's a situation more common that Microsoft seems to believe.

    Soapbox: One of the issues I have with WSE 3 is that so much effort was put into hiding the mechanics within the insanely opaque policy files while the API itself is harder to use (relative to WSE 2.0).  But now all efforts are now being put into WCF -- which is practically hostile to plain old XML.  You might want to look at Martin Gudgin's sample code for implementing an STS using WCF: http://pluralsight.com/blogs/mgudgin/archive/2006/06/19/28503.aspx


    Friday, January 5, 2007 2:33 AM
  • thanks for taking the time to consider my post - much appreciated...

    Friday, January 5, 2007 4:39 AM
  • Hi Roger,

    I am also facing the kind of problem faced by you.

    I wish to to get my webservice authenticated for the first time and then onwards want to add the authenticated response in the soap header in WSE 3.0.

    Please mail me at thompson2000seattleATyahoodotcom in case you find some solution for this.


     Roger_Melb wrote:

    thanks for taking the time to consider my post - much appreciated...

    Monday, January 8, 2007 5:12 AM