views:

27

answers:

1

I have been doing some research lately about best approaches to authenticating web services calls (REST SOAP or whatever). But none of the Approaches convinced me... But i still can't a make a choise...
Some talk about SSL and http basic authentication -login/password- which just seems weird for a machine (i mean having to assign a login/password to a machine, or is it not ?).
Some others say API keys (seems like these scheme is more used for tracking and not realy for securing).
Some say tokens (like session IDs) but shouldn't we stay stateless (especially if in REST style) ?

In my use case, when a remote app is calling one of our web services, i have to authenticate the calling application obviously, and the call must - if applicable - tell me which user it impersonates so i can deal with authorization later.

Any thoughts ?

+1  A: 

So, you have User -> clientServer -> yourServer, yes?

You need to authenticate clientServer -> yourServer, to make sure not just anyone can talk to your server.

If this is an established trust relationship (i.e. you guys chat, sign documents, and do other things "out of band"), then you can simply use SSL certs, certs that you can sign.

Basically you set up your own Certificate Authority, create a root certificate, and then create a client certificate signed by that root certificate.

You then send that certificate to the clientServer, and don't let anyone connect to your service that doesn't have a certificate signed by your root certificate.

If the client ever ceases their relationship, you can revoke their cert and they can't talk to you any more.

As for identifying the User, that will need to be part of the API. The Client should authenticate them properly, and then forward any credentials to you that you require.

That can be a first class part of your web service (like a parameter), or if you use SOAP it can be passed along in a SAML attachment in the SOAP header, that you can then extract.

WS-Security has about 8000 ways of securing SOAP web services, as you may have discovered.

So, it kind of depends on what you want to do, and other requirements. But given what little you have, this should work peachy.

Will Hartung
Thanks for your geat answer Will,This is clear enough now. I was just afraid to start working on some architecture that wouldn't be "The whay most of them do it out there".You know, reinventing the wheel :)
redben