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.
Related
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.
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 have a WCF service hosted in IIS. I have another website hosted in asp.net mvc. It is a public web site. I want to secure my WCF service so that it won't be accessible from any applications other than my MVC application, or which I give access.
Can I do this using forms authentication?
Update:
I had gone through several examples, but I couldn't get an effective one. I dont want to use ssl. Login feature is not there in my web spplication. If required, a programitic login can be implemented. All I need is, deny access if the service is not called from my website. I've done this in web service using forms authentication. But here, the httpcontext is null.
Yes, you can. WCF calls go through the same pipeline so that if you check for specific principals (usernames or roles), your checks will fail/succeed depending on the Forms cookie.
More details in my blog entry
http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html
where I show how to share the forms identity between a web app and hosted silverlight app which calls WCF services.
In case of yet another type of the client application, the way you get the cookie value at the client side can vary. Silverlight just inherits cookies from the web application it is run from.
Assuming your client is a console application, you could even expose an unguarded method from the WCF service which accepts loginname+password and returns the cookie to the client. This way, the console application would first call this unguarded method to login the user and then, using returned cookie, would call other WCF services guarded with forms authentication.
I have a MVC website that uses ACS as an authentication provider.
The authentication process works well.
I want to call a WCF service that requires authentication and I want to pass an RST token but I don't know how to create it
The key question is what identity is the WCF service expecting. If you can use an identity for the entire MVC site (a.k.a. "Trusted Subsystem"), then it is business as usual: you would need to get a token from an identity provider that the WCF trusts and that's it. ACS could be one, but it could be something entirely different too. It really depends on who owns the WCF service.
If, on the other hand, you want to flow to the WCF service the original user identity (that is the caller of the MVC site), then you are in a delegation scenario. This is possible, but it's often complex. Search for "Act As" (here's an article that talks a little bit about it: http://msdn.microsoft.com/en-us/library/ee517268.aspx).
In a nutshell, the MVC app would request a new token to the STS using as input the original token the user submited, with a special condition (the "Act As"). This condition signals the STS of the delegation.
As I said, this is a farily complex setup. Also (last I heard) ACS doesn't support "Act As" requests.
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.