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.
Related
I am attempting to make my ASP.NET MVC web app provide SSO to multiple IdPs, and I am wondering if it is possible to support this scenario using the ITfoxtec.SAML2 library.
I have many different clients, several of whom want to have an SSO integration with my service. Each of the clients has a different sub-domain (e.g. business1.myapp.com, business2.myapp.com, etc.) and I will need to use their unique part of the name to look up their metadata and produce a configuration that will talk back to them.
The example code that I have seen seems to be supporting a more traditional one IdP to one SP scenario.
Additionally, if any one knows of a non-Core ASP.NET MVC example application, I would be profoundly grateful to know where to find it.
In your case I would implement some Saml2Configuration logic, where I can ask for a specific Saml2Configuration for the current IdP. This specific Saml2Configuration is then used in the AuthController.
After a binding.ReadSamlResponse(Request.ToGenericHttpRequest(), saml2AuthnResponse) with a generic Saml2Configuration you can read the IdP issuer in saml2AuthnResponse.Issuer. And then load the correct Saml2Configuration.
A link to a non-Core ASP.NET MVC relaying party sample application https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestWebApp
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
These are Application Types and Scenarios that Azure AD supports:
Web Browser to Web Application
Native Application to Web API
Web Application to Web API
Daemon or Server Application to Web API
I have two questions:
I would like to understand where my scenario below fits.
I think I need to use JWT tokens and it seems that Native Application to Web API is the closest,
but I still need Asp.Net MVC application to deliver Client side Angular MVC resources (html templates, controllers and Rest services)
Which Azure Active Directory Code Samples are the closest to my scenario below:
I would like to create a multi-tenant Angularjs (delivered using Asp.Net MVC 5) and Rest Web API 2 secured with Azure AD. I would like to have tenants choose their domain names like firstTenant.com,
smt.firstTenant.com or to have subdomains like firstTenant.MySaaS.com, secondTenant.MySaaS.com
or MySaaS.com/firstTenant, MySaaS.com/secondTenant or similar domain naming scheme.
I would use some kind of IoC container to add customization to my SaaS application or similar to deliver specific functionality to each tenant (GUI and business logic and DB).
I would use and Asp.Net MVC application that will custom tailor SPA resources (html templates, .js controllers, .js services, .css, images etc) to each tenant and use some partitioning techniquest to retrieve tenant and user specific content from DB called from Rest API controllers.
Thanks,
Rad
I am also facing the same 'i dont know' issue :)
But far as i have researched the authorization flow from SPA aplication to the web api.
You still need webserver(mvc) project that will privide redirecting to the Identity provider (azure AD) login page and on the IP callback you will need to inject baerer token to Angular auth service that will send token to the api or deal with the refresh token.
So for me I think that, Web Application to Web API, is the right direction programming.
pls comment if i'm wrong
Currently i'm investigating link
http://code.msdn.microsoft.com/windowsazure/MyCompany-demo-applications-eedab900
update 2:
http://www.cloudidentity.com/blog/2014/04/22/AUTHENTICATION-PROTOCOLS-WEB-UX-AND-WEB-API/
Maybe it will be helpful to us.
I'm re-developing an app as a web app (the "previous" iteration was in VB6) to run on azure. One requirement is that we only use facebook/google authentication (OAuth 2.0). Another business requirement lead me to break my project into the following schema:
1 Project for the WebAPI 2.0
1 Project for Controllers
1 for Data Access (typical layer pattern)
N Projects for MVC 5 front-end
The idea is that the MVC projects will only consume the WebAPI via javascript/json! The N MVC projects will contain just the GET implementation for the pages. No models or others actions (post for example). In other words the MVC projects are completally disconnectd from the other projects and should have no intelligence what-so-ever!
This is the selected way because of (bitchy clients and) limited time constraints.
Anyway, as you can notice the "core" (WebAPI + controllers + DA) is shared. The core is in fact a multi-tenant service. (but remember the disconnected facet!)
My problem here is: How do I handle Authorization? What/how should treat the passing of the claims between the MVC projects and the WebAPI? Im lost here. After some thought, I came to the conclusion that I need to make the WebAPI project act as a proxy here, something like:
Random users lands on www.myClientWebsite.com/Register
Chooses a login provider
The MVC project redirects the user signaling facebook to return to www.myWebAPI.com/Register
I intercept the claim and redirect the user to the original www.myClientWebsite.com/LoginComplete or something...
Am I getting it wrong?
You have to use OAuth 2 for authentication and authorization purpose in this scenario. Yes, you should be making the authentication at the MVC level and then use tokens to keep the security intact for rest calls.
Here your MVC application should get a Bearer token from the identity provider like google and then hide it some where on the form. Then for every jquery request you make to web api, you have to send this bearer token in the request.
[Update]
This is considered kind of hack and I do not encourage it. And this works only if both the systems are in same domain.
[\Update]
If both MVC and Web API are on different domains, then you can think of using Azure ACS Service Identity to build the trust between domains. Then pass the bearer token of User claims in the payload of the request.
[Update]
This is much more better way to handle this but must be accompanied with proper token revocation and https security.
[\Update]
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.