(I tried searching, but couldn't find any truly helpful links.)
We are implementing a set of WCF services. What I would like to do in these services is have the clients (which will be trusted application servers) be able to pass a token of some sort to the web service to authenticate. I do not want to be required to pass username/password on the initial or subsequent requests (because in some cases the calling application server may not have the password). Windows and Kerberos are not usable in our specific circumstance.
I had thought to just create a simple custom UserNameSecurityTokenAuthenticator class and modify it so that if the password is empty, it takes userName as the string-encoded token value (obviously checking the token itself to verify that it's valid at that point), but if the password is not empty, forwarding on the username/password to a MembershipProvider for checking. Basically I'd like to overload the username/password authentication to provide for token passing as well.
Is this possible? Can I simply plug in a token authenticator like this, or is there some other simple way to "intercept" requests like this (and update the actual username value from the decrypted token)?
Or is there some other incredibly simple way to allow the client to pass a custom token and have the server accept it that I'm just missing?
If it's a fairly controlled environment and not too many clients involved, then I'd try to set up something along the lines of the B2B scenario securing the transport link using certificates on both ends.
Certificates are not bound to Windows or an AD domain, and setting them up is a one-time job.
Read more about that WCF security scenario:
MSDN: Transport Security with Certificate Authentication
Fundamentals of WCF Security: Business Partner Applications
. WCF Security How-To's
Related
I'm currently using Thinktecture's Identity Server as a security token service to handle the issuing of tokens based on username and password claims. This fits perfectly for a scenario where the authenticating client is an actual user authenticating against a web application for instance, but I'm now interested in scenario for when the authenticating party happens to be an independent process on the server that needs to establish a security token to pass to another server process. I'm ideally after a few pieces of advice here:
1. Is this a valid approach to authentication for server processes communicating with each other?
2. What if I were to move one of the server processes to a different machine talking across a TCP boundary instead perhaps? Is this approach still valid.
3. What ClaimTypes would I use for authentication of the process? And is the Thinktecture Identity Server happy to authenticate against these? I assume I'll probably have to write a custom authentication extension to it to do so...
Thanks very much,
Clint.
One of IdentityServer's authentication protocols is the "simple http" -- you pass in credentials and get back a token. This might be what you want.
Oh, there's also the WS-Trust endpoints as well.
I have to implement public WCF service which can be consumed by known client. I also want to authenticate client using custom identity (not windows authentication).
I have explored WCF security for authentication with custom Username and Password. Since I have to implement the solution for Hetrogenious network, I cannot use windows authentication.
I have found two ways through which we can incorporate custom authentication in WCF. I have few queries on each of the approaches as below.
1) Through "UserNamePasswordValidator" class. We can create custom username password validator and validate user from the database. This approach is perfectly fine to implement SSO (Single Sign On) as each request has credentials in SOAP header. Client doesn't have to validate himself before each request.
Questions:
Is this approach is easily extensible for Authorization as well? Since authentication happens before service call by getting credentials from the SOAP header. Also credentials are not a part of ObjectContext, I have feeling that authorization approach is not straightforward.
To follow this approach we need to use Brokered Authentication pattern and for this we need third party certificate. Is this advisible to go with this approach as we have to add cost of certificate in a project.
If we use message security to encript the message why we need a certificate? Just for Client identity? Cann't we just use self signed certificate in production since we know who will consume this service?
2) Through "ServiceAuthenticationManager" class. I know only one approach using this class and that is to implement solution using Direct authetication pattern. Also after authenticate user, we need to supply it's identity or token through custom header for all subsequent request coming to service to implement SSO (Single Sign On)
Questions:
Is this a valid approach for public service? Should we enforce user to supply credentials (or token once provided by our service once it is authenticated) via custom header in each request?
This approach doesn't required certification and so we can save its cost to the project. Is this enough reason to pick this approach?
Personally I feel the first approach is easy to implement and it is more standard way to implement authentication in WCF service but the only problem is we need third party certificate.
Please answer my query and if possible suggest the best approach for my requirement.
Thanks,
Ankur
I've been reading about WCF security for a whole day and can't say I'm comfortable with it.
I've developed some WCF services and deployed them to a test server and can call from a client. Both sides C# / VS 2010. The services are hosted under IIS 6. No option to go more recent at the moment.
So - I've read that I can only use HTTP with IIS 6 - which I believe restricts me to basicHttpBinding or wsHttpBinding as the binding.
I've also read that the XML sent over the wire using wsHttpBinding is encrypted, whereas basicHttpBinding is not.
So it looks like I want to go with wsHttpBinding as I will want some sort of authentication and I suppose user name / password will be passed along with the incoming messages.
First question is - if I use wsHttpBinding do clients have to call using https? And then do I need to worry about certificates etc. on the server?
Second question is - what security options are available to me? Do the callers have to be Windows users on the server, or can I make up my own user name / password and have that part of the service and the service do the validation and have nothing to do with Windows users? If I have to go with Windows users I suppose it's common to set up one user account on the server and have all callers use that?
The basic idea is I need to open this service to selected callers, but don't want just anyone to be able to discover the service and call it. I need to control somehow who calls the service. Is user name / password the standard way of doing this? Could I define a GUID for example which all callers would have to pass?
In answer to your first question. wsHttpBinding does not require HTTPS. You can use HTTP if you set the SecurityMode to Message or None. However, since you are proposing to send a username and password with the service calls you definately shouldn't do that. If you do then anyone will be able to look at the message in transit and read the username and password and your security is totally compromised. I'm afraid you will have to get a certificate and use HTTPS. It's not so bad though and there are lots of resources on the web to help you.
By the way, you can do HTTPS with basicHttpBinding aswell as wsHttpBinding. Also, you should consider using REST for simplicity. WCF has good support for it (webHttpBinding) and better support coming with the Web API.
In answer to your second questions, you do not need the callers to be Windows users on your server and you can use a username and password. This is called Basic Authentication. Again, there is lots about it on the web. Start here.
If you do this you will obviously have to have a database to store usernames and password so you can validate then and grant or denay access to your service. The simplest way to achieve this with WCF is to use one of the default membership providers.
We are using WCF services. Right now, we are using Windows Auth but this is not for long. Some services will sit outside the firewall and use username/password verified in the database.
My tech lead is "scared" at how easy any user can "Add Reference" to the services we have and just party on. He wants to "guard" the services by adding another identity - the application. He wants the service to accept requests from certain applications so the certain users cannot just use the service - add reference to it and call. It’s the notion of the application having an identity + credentials that is the operative principle here, as services on the network may need to authenticate those credentials prior to fulfilling a request, in order to prevent rogue code inside the network (i.e., NOT the application) from accessing services using “Joe User” end-user credentials.
Does this make any sense?
Then he believes the Juval Lowy's book has, in an Appendix that discusses sending more than one identity during a WCF call (Security Interceptor). There is no specific suggestion that all of those have to be end-user identities and if that is the case, one of those could be the identity of the application making the request.
How can this be done?
Thanks,
Sam
The problem with sending an application identity is that the secret used to confirm that identity has to be stored somewhere. If it is visible to one application on a machine then generally it will be visible to other applications running under the same identity.
Would your manager be happy with "it came from an authorised machine"? If that's the case you could simply use Client Certs
Its also worth taking a step back: if the user is authenticated and is authorized to perform the functionality they have requested, why do you care which application they came from - if they are who they say they are and they are allowed to do what they are requesting then why couldn't they use, say, fiddler to make the request - isn't that the point of a service (rather than a closely coupled client server app)?
You might want to look through Common Security Scenarios in the MSDN documentation to see if any of those options fit your needs.
The options that pops to my eye are Transport Security with Certificate Authentication and Message Security with Mutual Certificates. Both rely on X.509 certificates. The latter option is on the message level, so you can handle certificate delivery and security negotiation however you want.
To make it a lot harder for someone to add a reference to your service you could just remove the mex endpoint. This way it would be very difficult for a stranger to create a valid request message.
You can then distribute the WSDL manually, only to people you trust.
I'm writing a set of WCF services that rely on transport security with Windows Authentication using the trusted subsystem model. However, I want to perform authorization based on the original client user that initiated the request (e.g. a user from a website with a username/password). I'm planning to achieve this by adding the original user's credentials in the header before the client sends the message and then the service will use the supplied credentials to authorize the user. So I have a few questions about this implementation:
1) using transport security with windows auth, I do NOT need to worry about again encrypting the passed credentials to ensure the validity... WCF automatically takes care of this - is this correct?
2) how does this implementation prevent a malicious service, running under some windows account within the domain, to send a message tagged with spoofed credentials. for e.g. a malicious service replaces the credentials with an Admin user to do something bad?
Thanks for any help.
What binding are you using? Is this service only within your corporate LAN, or do you plan to go outside the firewall?
To answer your question (as far as I can)
1) With Windows authentication over transport security, the transport layer will be encrypted and safe - no need to worry about additional encryption of credentials etc.
2) It cannot. If a malicious service manages to "hijack" some valid Windows credentials and poses as "John Doe" who has an account on your corporate network, there's no way the WCF service can distinguish this from a valid request by John Doe.