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
Related
I have a web service that acts as a OAuth 1.0a provider. Web applications go through the OAuth 1 workflow to gain access to user resources. So far so good.
The client web application has the need to communicate with the service for other needs, to exchange private data NOT linked to a particular user/resource owner. For that, a good idea seems to use OAuth2, in particular Client Credentials Grant (4.4)(which was designed exactly for this).
From a "confidential client" (and a web application falls into this category, according to the OAuth specs) you can directly authenticate your client and get an access token.
EDIT: of course, the kind of web application I am talking about is html+javascript BUT authentication and communication with the provider/web service happens entirely server-side. Credentials (client secret, keys, etc.) are all stored on (and never leave) the server.
According to the specs, authentication can happen with "username+password" (client password with HTTP Basic authentication scheme) or "other authorization methods".
I was not able to find any clue of what these "other authorization methods" may be.
Since we use private/public key pairs for OAuth1, can we use them for this task too?
The specs seem very liberal (and very vague!) on this point.
I would like something that is supported by the various libraries, so that a 3rd party client can implement it easily using standard libraries (like DotNetOpenAuth for example). If needed, it is reasonable to assume that some coding needs to be done for the custom method, as long as it can accommodate existing libraries (plugin?)
Is there anything "standard" or easily usable other than HTTP Basic, for OAuth 2 authentication?
If by web application you mean a JavaScript and HTML app that runs in the client browser and needs to make secure requests to your service, that is not a "confidential client". You cannot store secrets in a browser based app, as they will be visible to all.
If by web application you mean a server-side application that needs to make server to server requests, that is a "confidential client" because the executing code and secrets are not available to public scrutiny.
I interpret the "other authentication methods" to mean any authentication scheme that is customary over http (or https) that can be completed in one request. Client certificate authentication using TLS might also fall into this bucket. I think the main part of the OAuth2 4.4 Client Credentials Grant is that the client app presents credentials directly to the OAuth token service via existing authentication methods. The example uses HTTP Basic authentication, but that's just one example.
Client credentials grant differs from the resource owner credentials grant (4.3) primarily in that the resource owner grant presents the user credentials in the body of the http request instead of in the Authorization header. It would be difficult to use other authorization methods with resource owner grant.
The greatest caveat in using other authentication methods with the Client Credentials Grant is that support for anything other than HTTP Basic auth by OAuth2 client libraries will likely be spotty at best. Even if your use of digest or client cert auth with Client Credentials is within the OAuth2 spec, I'm doubtful that existing OAuth2 client libs will have built-in support for your particular permutation. See if you can find examples of client credentials grant using anything other than HTTP Basic auth by some of the big players such as Google or Yahoo. Things used there are more likely to be supported by OAuth client libs (especially the libs they ship!).
If you own both ends of the connection, this doesn't really matter. You can do whatever you want and find a client lib that will let you tweak or tailor the request to fit your needs.
If you want arbitrary clients to connect to your service using client credentials grant, you should plan on providing documentation and sample code of how clients should present the credentials you require. Off the shelf OAuth2 client libs probably won't provide automatic support for your scheme.
I have been looking at the Thinktecture.IdentityModel.40 library as a way of handling the security of my Asp.Net WebApi. One point I don't understand is the following, and this is my question.
When the user authenticates the first time, they need to supply their username and password. If they are authenticated, they are issued a token to use for all the other calls.
Using the above library, I use the method, AddBasicAuthentication to the security config.
Will this by default use the token issuing mechanism, or do I need to use the AddSimpleWebToken?
And If so, how do I tie the two mechanisms together?
There is no token issuance yet. I am working on that feature.
Can someone guide me on the best practice for this situation;
I have a REST service which developers can access with an API KEY. (I have this working in the WCF WEB API), so this part is done.
I would like developers to be able to validate a USER. i.e. use REST to check the username and password entered by a user.
Each of the end point methods only needs API KEY authentication, rather than basic authentication on the method call (if you see what I mean).
How should I best implement this?
Phil.
To securely send password data to a RESTful service you will need to secure communications across http. There are loads of ways to do this, see this post here:
How to secure RESTful web services?
I am working with WCF Webhttp services. I have created a bunch of services and all that remains is to put in user authentication...
Questions
Keeping with the rest architecture style, should I authenticate each service call against the user db.
If so, I should just do authentication by supplying the credentials and password each time the service is called and make it secure with SSL. Basically, each webget/webinvoke function should contain the user credentials as parameters and I authenticate each call. Is this right? This seems rather inefficient.
Using session key somehow seems wrong but any pointers as to how to use Session in WCF Webhttp?
I am not working with ASP .net membership (will be looking into it soon) since I was working with Mysql and have my own registration/user database created. Should I be looking at that? Can I use a wcf authentication service along with wcf webhttp services?
Any literature on handling authentication in WCF webhttp services would be greatly helpful.
Many thanks
You can check Chapter 8 of RESTful .NET book (Amazon, Google books)
You will authenticate only the first call from the user, any subsequent calls will use the context of the authenticated user. There are several options how you can use SSL(TLS), like always or just when you send username/password.
I am not sure where exactly and how you store the authentication token (like in Session or similar type).
You don't need to use ASP.NET membership provider, in fact you may not use any membership provider at all, just use other authentication models. Usually, there will be only one authentication model per service, like you get the credentials, check them against persisted storage, if valid you set the security token and that token is used for all the next calls for a limited amount of time.
(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