I have been challenged with the task of coming up with an authentication/authorization strategy for a pretty big WCF API. My task is to implement security on this API from clients who might be a website, a mobile app, or an internal/network admin user (which is pretty much the goal of any solid API).
I have looked into Windows Identity Foundation and federated security, but it relies on WS-* and my clients might be using REST or a non-SOAP protocol. So, my question:
Is there a security strategy (per method call, preferably using attributes) for WCF that does not rely on SOAP or involve reams of configuration files?
I realize there's probably no catch-all solution. I'm really looking for ideas or suggestions. This turns out to be a really tricky challenge.
Basic Authentication and HTTPS is a straightforward and "secure enough" solution for most API authentication requirements.
When you say "per method call", I'm getting the impression that are talking about authorization. For that you are probably going to have to roll something yourself. The upcoming Microsoft Web Api framework has some good extension points that will make this type of functionality much easier to implement. It shouldn't be too long before someone implements a reusable module for this framework that you can just plug in.
Related
I wanted to know how can I implement the SSO authentication between multiple applications using the SAML in ASP.NET Core?
Is this a safe and secure way to do it?
If you know the information, better free method or how to implement it, write it down.
Thanks in advance.
I don't think free method exists. Unless you want to implement solution from scratch by yourself, which seems to be a lot of work to do.
So, if it's an option you could use some commercial solutions. I have experience working with ComponentSpace.Saml2. Configuration is pretty straightforward - you need to fill and store a bunch of configuration items such as identity providers' params, certificates data, login and logout endpoints. Then controller needs to be built, containing methods for initiating saml request and processing response from identity provider. That's just infratructure level - of course you'll need to implement authentication service to manage SAML response and to decide how it integrates into your app's architecture.
Well, as you can see, the answer is general, so is the question.
Hope this helps. At least to choose right path to go.
I'm about to implement the authentication module of my ASP.NET Core application.
I think I already know the answer for the following question, but I just want to make sure I am right, because I have been wrong before about some conceptions of IdentityServer.
Question: Is there ANY benefit of having the clients go through a single-point API that will centralize the access to the IdentityServer?
Answer(?): From what I understand, the IdentityServer is an implementation of the STS in the OpenIDConnect protocol, and the IdentityModel different libraries are yet again an implementation of the protocol, in the client side.
Therefore, even if I replace my IdentityServer with antoher STS - my clients won't have to change, if I configure my new STS to behave the same.
Can anyone approve the above? I'd rather make the mistakes now and not after I start :)
I'm in the process of setting up a WCF Data Services web service and I'm trying to sort out the security configuration. Although there's quite a lot of documentation out there for configuring WCF security, a lot of it seems to be outmoded or does not apply to my scenario.
Ultimately, I am planning on managing authorization of operations via change interceptors. Thus, all I really need is the simplest way to permit a client to pass credentials along with a request and to be able to authenticate those credentials against either AD or an ASP.NET membership provider (I'd much prefer the latter unless it makes things much more complicated).
I'm intending to manage encryption at the transport level (i.e. HTTPS).
I'm hoping that the eventual solution does not involve a huge web.config. Likewise, I'd much prefer to avoid writing custom code for the purpose of authentication.
In the following links you have a series of OData authentication options. If you don't know exactly what you want then that is a really good place to start and see what options you have.
Part1
Part2...
An exploratory question, here. After some reading, I'm getting a sinking feeling that WCF's authentication options aren't "friendly" to non-Microsoft clients, or require a great deal of effort to implement. I'm building a REST WCF service for which I wanted some kind of simple digest authentication; e.g. I store a username and password in Web.config and share that with the team that will use the service. The team that will consume this service is a legacy shop not versed in Microsoft tooling or helpers; e.g. ANSI C/C++, PHP, etc.
Anyway, MSDN tells me that digest authentication requires that the server be in a domain. I don't want or need this service to be in a domain. That seems like an odd requirement. So I dismissed that option.
So I read about NTLM and Windows authentication, but I worry that I'd be imposing a burden on the other team by only supporting Microsoft-flavored, proprietary authentication methods; won't they have to put forth a lot more effort to code against such a service? These methods seem intrinsically tied to concepts like Windows domains and user accounts, etc.
If you just look for "friendliness" then you can go for basic authentication which is pretty much supported everywhere.
However, unless that is coupled with some kind of transport level encryption then passwords will be transferred in clear text - a pretty bad situation security-wise.
NTLM and kerberos authentication is supported by several non-WCF technologies does but a burden/requirement on the environment in which the are used.
You could look into some kind of message level authentication meaning that the credentials will be part of the message instead of handled by the transport. WCF supports the WS-* specifications that relate to message level security. Those specifications are again not tied to WCF or Windows.
I sounds like the simplest way in your setup would be to use basic authentication and use HTTPS for the transport.
Windows Authentication is intended for use in intranet services where there is a domain controller you can use to manage your credentials and authorization.
You need to check the Forms Authentication, that will probably meet your needs.
I'm rather new to the WCF/IIS/MS web stack corner of the world so I'm hoping for some help evaluating my design.
What I need is a system that presents a number of resources as URIs. Each resource is a WCF web service providing a number of read and write operations. I need to provide username/password security for different resources.
How I'm hoping to make this work is to have IIS handle the security using the normal devices it uses for everything else. Then uses URL rewriting to remap everything to a single web service that will provide the correct resource based on the rewritten query string.
Will this work?
Am I missing something?
Is there a better way to do this?
If you happen to known of a really good tutorial for the bits and peaces (like what file does the security settings go in?) I would appreciate links?
For now there will be only a handful (2 to 20) users so static config files would be preferred for that as along as it won't cause problems later.
As I said, I hardly known jack in this domain so I don't really known what I don't known.
A few links I have found (don't even known yet if I'm looking in the right direction)
Fundamentals of WCF Security (assumes a bit more familiarity than I have)
Improving Web Security: Scenarios and Implementation Guidance for WCF (really long, book length)
Yes this sounds sane. For authentication you want to use ASP.NET membership module it provides a generic security API which can use intergrated (windows user), web form login, even LiveID or some custom authentication. In my experience MSDN has proven a good resource, here's a hands on article.
For web http binding WCF provides Uri rewriting out of the box using WebGet attribute.
for SOAP, the end point URL is the same, so I assume you want RESTful endpoint. If so, you need Basic auth over https not WS-Security.