Partager via

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

Comments

  • Anonymous
    May 30, 2007
    PingBack from http://blogs.msdn.com/alikl/archive/2007/04/11/authentication-hub.aspx
  • Anonymous
    May 30, 2007
    Well I'd take fiddler, see what's going on over the wire after successful communication and then I'd  launch another client on the same machine that will repeat successful request over and over.
  • Anonymous
    May 30, 2007
    besides - this solution is not scalable - what about other potential clients ?
  • Anonymous
    May 30, 2007
    Anatoly, thanks for the comments!Re Comment 1The Web Service is called from the server by ASPNET runtime and passes the cert that is accessible to ASPNET working process account. This account and the server too usually accessible to administrators only. So to run the fiddler you need physical access to the server. If an attacker has physical access to your Web Server – end of story, it is not your server any more – forget certs and other veggies. To make reply attack successful with certs you need access to the cert otherwise Web Service side authorization will deny your request even though you have the whole SOAP message exactlyRe Comment 2Yes it is very NOT scalable solution for end users, but again – consider that the client cert identifies ASPNET application on behalf on its thousand users. So if the users authenticate to ASPNET site using AD and then the ASPNET web site calls into Web Services using it client cert – kind of authentication gateway or more properly “trusted subsystem” – than it is very scalable, since end users are managed in AD and few certs only managed on both sides for creating trusted connection. Now the real question here is how end user identity passed to the web service. It is kinda one million dollar question that WS-* circus tries to solve. For example our very own ADFS is a good example for WS-Trust implementation but currently it supports only browser scenarios and not Web Services like in our case.What other path would you take?
  • Anonymous
    July 04, 2007
    I was delivering "Authentication Explained" session for Security User Group. First of - thanks for attending
  • Anonymous
    July 04, 2007
    I was delivering "Authentication Explained" session for Security User Group. First of - thanks for attending
  • Anonymous
    July 04, 2007
    I was delivering "Authentication Explained" session for Security User Group. First of - thanks