SOA, Strong Authentication, Standard Authorization - Cool Solution

  • Article

 

reposted from here

I've previously blogged about SOA Security Inside Enterprise walls

This time I had couple of pretty interesting requirements from one customer that targeted B2B/Partners scenario. They had a web site that communicates to partner's web services. His concerns were sincere and pretty fair:

  • I want to manage my creds that I use to authenticate with the partner's web service in secure way
  • I want to pass it it over the wire in secure standard way
  • The partner won't do any major changes to his authorization schema inside the web service
  • Authorization schema must be easy to managed and standard

Without any hesitation I've gone to the following topic -

How To: Call a Web Service Using Client Certificates from ASP.NET 1.1

and implemented step by step what was described. In the code you see that one needs to  export client certs. Customer's concern was about how safe the cert is, no worries - it is getting exported without private keys:

Last thing what I needed to do is Web Service authorization, so what I've done is I mapped the client cert to windows account on the web service machine like this:

Then in the web service code I've applied standard Role demands (well specifically here I demand specific user, but it could be group too like "...Demand, Role =@"myServer\Group8"") 

And when the app was calling the web service method it was picking the client cert and sending it over to the web service which in turn was mapping it to windows account and the principal permission was applied to this account. When I was calling HelloWorld1() everything was fine since it was protected by user demand to which the cert is mapped to, on other hand HelloWorld2() was rejected since the cert I was sending is NOT mapped to that user. Man, these are those rare moments that I am happy to see exceptions :) 

Conclusion:

Using minimal of coding (client side - couple of lines, server side - one line for each method) and standard configurations of the infrastructure I've achieved:

  • On caller's side the creds are managed in standard secure way - the client cert sits in User Store
  • Client certs authentication is considered one of the strongest authentication mechanisms
  • All the data goes over secure communications - SSL3
  • Web Service utilizes standard .Net authorization mechanisms which required no coding (almost)

Now tell me why it is not COOL :)

Cheers