I am starting a new product that will require a .NET based server (using WCF) hosted on Azure. I would like to have basic authentication and security features. The clients are all "rich" UI but are not neccessarily microsoft ones.
We intend to have the first client application written in Silverlight, but we want to keep our options open to implement clients for iOS and Android in the future. So we do not want to use WCF specific features but rather protocols that are easily available on other enviroments.
Of course, with the Silverlight client, we hope to get as much done for us automatically as possible. We intend to only communicate through web services.
Which bindings are recommended for such a scenario?
How would you implement security? (assuming we need basic security - Users being able to log in with encrypted user and password and perhaps some built in basic role management althouh this is optional).
Suggestions?
You could use WCF to implement a REST interface
The binding would have to be a basicHttpBinding (to be open to all platforms) and using SSL to secure the line.
Managing credentials could be done using tokens to be passed back and forth after authentication. Much like a http session. You could pass the token using a cookie but the token could be part of the API or Headers as well. See this Best Practices for securing a REST API / web service
This would grant you the power of .NET and WCF without losing interopability.
Related
I have two client applications : Asp.Net MVC Core web app and an Android native mobile app, and an IdentityServer4 Server as an OpenID Server`.
I know that I have to create two client records for both of them (in the IS4's Clients table) :
a Hybrid Flow for the web app
a Hybrid/Authorization Code + PKCE for the native mobile app
But I'm wondering if I can create only one Client info for both of them or not?
I think you should create one client definition for each client, so you better can separate them and better evolve them as needed over time. Also makes it easier to separate them in the logs for example.
A question is however why/if you really need to support the hybrid flow? I think both clients only need to use the authorization code flow.
If you want to follow OAuth 2.1, then there are only two flows to use, either authorization code flow or client credentials flow. All other flows are not recommended due to various security issues. See https://oauth.net/2.1/
Tore's answer gives good reasons to keep those clients separated. If you're still not convinced, I would turn the question around - why do you want to have one logical client data used by two separate clients? This will cause some weird issues in the future. For example, at some point you might want to rate-limit one of those clients, or change client authentication method, or even block one of them completely. You will have to do it for both your apps if you don't create a separate client.
From the security point of view, there is a good reason to keep those two separated: the web client can be a confidential client with a secret assigned. The mobile client will be a public client, without a secret*. This is a solid reason not to mix those two, as you will lower the strength of your security considerably.
*In fact, best practice would be to use DCR and register a new client for each device where your app runs.
I believe the short answer to my question is "No", but allow me to describe the context.
We are currently using IdentityServer to authorize access to our APIs (via client credentials). All of the API clients are computer programs which run in our data centers and are under our control. In order to minimize our attack surface, our IdentityServer is running from an internal/private network, reachable from our APIs, services, and other apps. No problems.
We now want to leverage the IdentityServer installation to provide user authentication for our public-facing web applications. These applications run via ASP.NET MVC and will consequently require user interaction with the IdentityServer for password validation (implicit or hybrid grant type). This appears to be a hard requirement, but I'm curious if there is a simple way to maintain the private installation of IdentityServer.
Can we proxy requests from the ASP.NET middle-ware for handling the authentication handshake, and does it even make sense to do so? I'm leaning towards a public-facing STS to eliminate any proxying, but thought I would ask to see what other patterns are employable.
For what its worth, we would ultimately use cookie-based authentication with the hybrid flow, but would be able to start with the implicit flow too.
The user's browser must be able to access the identity server. This can be via a proxy though.
I got a MVC web application that authorizes users through Azure ACS. Now I want my web application to make calls to my WCF services. Since these services can be called by other applications I want them to be secured through ACS also. I'm at a loss on how to set this up. Can I reuse the security tokens in my WCF service calls somehow?
Formally you can't because these are 2 different (autonomous) "apps". Tokens are issued for a specific app (or "Relying Party"). Your website should request a second token for the web service. You have 2 options:
1- Simply get a token under a service identity (that is the identity the web site is assuming) and attach it to your calls to the web service. WCF bindings support this out of the box (albeit complex, as any WCF configuration),.
2- Get a token for WCF "on behalf" of the original user. This is a delegation scenario, in which the identity of the original caller to the web app is transferred to the service.
The first option is rather simple (putting aside the WCF specifics). The second option is more complex one and not supported in ACS (as far as I know), because it requires a special endpoint that understands and issues ActAs tokens.
You could use the same token for both the web site and the service if you own both and are "the same app". This is a pragmatic shortcut and not a pure implementation, and might have other implications (e.g. the same app in ACS, the WCF can't easily distinguish that it is being called from your website or external parties, etc).
In that case, the MVC app must keep the token that was sent to it. There's a setting for that (bootstraptoken=true). The WIF API in .NET 4.5 changed a little bit, so there might be something else.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH