So I am trying to secure an ASP.NET Web API Service so that an iOS (iPhone 4/5) application can access it RESTfully using their Windows user name and password (don't ask :) ), and I have followed this article here, and for the most part it works, I just modified it a little to use Active Directory Services to validate the user name and password, but I am wondering if there are better ways to secure a ASP.NET Web API that will be used from non-browser clients as well as browsers possibly?
This is hosted with IIS7, so should I just let IIS control the authentication?
Need a little guidance... Thanks
It's a bit unclear specifically what you are looking for, in my experience assuming I'm authenticating against a server the keys were
Put access to the APIs behind https
Send the request via POST.
If you're also coding the iOS side, make sure you are implementing authentication challenging properly. Here's an article on the iOS side: http://mobiledevelopertips.com/networking/handling-url-authentication-challenges-accessing-password-protected-servers.html
Related
My company is wanting to implement OpenID Connect via Oauth 2.0 across our client software, which comes in Windows, HTML5, Android, IOS, etc. Toward that end, we are trying to find a way of getting the login info back that will work across these platforms.
Our understanding was that a custom uri scheme (i.e., companyname://) was the recommended way of going forward, and we have verified on our end that that would work. However, we have yet to be able to find a provider that would support that configuration. So far OneLogin & Google are both locked to https:// (or http:// for dev), which leaves us something of a conundrum.
So essentially, my question is, were we misled about the custom uri scheme? If so, is there another method we can use that will allow our web & standalone apps to pick up the return info from whichever OpenID providers we go with? We want to keep it open as possible, so we're trying to avoid lock-in APIs and suchlike. Any advice would be appreciated. Thanks.
We do support the custom URI redirect. You'll need to select right type of client when creating a client id on Google developer console.
See the details here.
https://developers.google.com/identity/protocols/OAuth2InstalledApp
One way to support any provider is that you use a Web flow to redirect to a page on your site and then your website does a redirect to a custom scheme.
Can someone explain to me how to achieve single-sign on? I have an MVC ASP.NET core web app(let's say www.internalsite.com), how can the app get the user credentials automatically and authenticate etc.? I need a very clear explanation on how to do it.
By using www.internalsite.com I guess you are talking about a site on an intranet, right? How are you hosted? IIS in front of Kestrel? If so, then it's quite straightforward, you just need to configure IIS to foward the Windows identity (coming from a Kerberos token usually) by setting the proper value in the web.config: forwardWindowsAuthToken="true" as explained here: Asp.net Core Web API - Current user & Windows Authentication and make sure you have a controller/action protected by an [Authorize] tag so that the IIS middleware is challenged and set the identity of the request as explained here: NTLM authentication on specific route in ASP.NET Core No much code to write in your project. If you are using another hosting setup, WebListener, it is pretty much the same.
Another solution, would be to do SSO by client certificate which has the advantage of working cross domain, but SSO by Kerberos is by far easier and usually doing a good job on an intranet.
Background:
I've implemented a Web-API (.NET), now I need to do the most important thing,
Secure it.
As I investigate this topic I understand that the common way is the Bearer Token.
Now we getting to my problem.
My Problem
On one side:
Every article I saw (that explains the concept and the way to implement it over .NET) starts from a project with a Web API template that holds MVC and Web API and in the authentication field choose one option from Individual / Organizational / Windows .
On the other side:
I don't need a MVC project, I need only Web API (without any GUI) that the reason I choose the empty project and check the Web API checkbox, in that way I cant choose an authentication type, I forced to start with no authentication.
Questions:
1.Do I bound to use MVC to get authentication ? if not how can I do it from pure Web API project ?
2.Maybe I will create an Authentication Server (that only generates tokens) from that Web API template (with the possibility of choosing authentication type) ? (and use the token on the real Web API)
3.There is any benefits of implement the Authentication Server on a different project and on different server ? (Kerberos style )
P.S I want to use an out of the box solution because the security aspect is the most important one (to my opinion) and should be flawless.
I wrote a blog on this topic called 'Securing and securely calling Web API and [Authorize]': http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx. I think if you read this, you'll have all your answers.
The Web API template does include MVC by default so that you get the automated docs feature (which is a great feature to have). However the authentication part is related to a core ASP.net feature, not specific to MVC or Web API. You'll need to enable one of the authentication options to secure your API using .net's built in security features.
If you do not want the MVC project that comes with Web API, just delete it after the project has been created. It is contained within the 'areas' folder. If you delete that folder, you'll be running on pure web api.
To answer your specific questions:
1) No you do not need an MVC project to secure an API project. You can use the [Authorize] attribute on your API controllers and actions.
2) an authentication server gets created by default with the web api template. You can access it and get tokens via http:///Token
3) No, you need to use the api itself to serve valid tokens for secured controller/action requests
Hope that helps. If not, then please be a bit more specific with your questions.
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.
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