I'm trying to create an MVC 5 app secured using WIF against Azure Active Directory. I'm trying to use SAML tokens with the following code:
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
Wtrealm = realm,
MetadataAddress = adfsMetadata,
TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
{
SaveSigninToken = true
}
});
The plan is to use the returned token to pass through to a back end WCF service. From my investigations, I understand I would need to use the "active flow" here, where the web app will need to request an access token from Azure AD in order to authenticate with the WCF service.
Is this flow supported by Azure Active Directory? Everything I am ready seems to suggest it's not, and these days we are very much steered towards WebAPI / OpenIdConnect.
I'm really keen to get confirmation one way or another on whether this is possible (with WCF) or whether it's time to give up on this approach.
Thanks
David
That flow isn't supported by Azure AD. Furthermore, your impression is correct- there is no explicit support for WCF in Azure AD, and although it is technically possible to arm-twist WCF to use Azure AD tokens, it is very difficult and requires heavy customizations.
I highly recommend considering web API moving forward, you'll find that all of our samples and SDKs from the last 5 years or so are all predicated on that.
Related
Couldn't configure the identityserver 4 authorization and bearer token authentication middleware in the same project.
It is now a built-in feature of Identityserver. Added with this PR.
services.AddLocalApiAuthentication();
And here is an official example of a protected API.
I suggest you make API and Identity Server in separate apps. This makes it a lot easier to maintain.
Identity server provides you the authentication against your clients/API's. The database operations , the business logic should be handled by your clients/APIs . So keep them in separate apps should be a better choice .
If you insist on making them in single project , you can click here and here for code samples.
You shouldn't.
The thing is that your authentication and your application are totally different services, with different scopes, and you should make them different.
This goes with Separation of Concern : if you want to change your auth service later, you won't have to modify your whole application.
Our application architecture is as follows:
1) WCF service acts as a facade layer and sits on top of Service, Business Logic and Data Access layer
2) Every client, be it an MVC/ASP.NET, or any other type of application has a ClientTag that first needs to be authenticated and issued an "access token". This token is then passed by the client with every message into the Facade layer
3) The system will be hosted on Windows Azure
This would have been easy to implement with WCF sessions like so:
1) Client initiates a call to WCF to get the token (Client to WCF Session is established, thus every subsequent communication is part of the same "conversation")
2) WCF authenticates the ClientTag, issues the token, and stores it as a local variable
3) Client stores the token in it's own Session and pass it to WCF with every request
Where it breaks down is the fact that Azure (due to its high-availability/load-balancing nature) doesn't support WCF sessions. So, the questions is how do we implement this.
One solution is to use AppFabric caching to imitate session state in WCF layer. We would store the Access Token there and then validate it against what the client passes in. The problem with this is that there is no concurrency between client and WCF. So, we would have to advance WCF session timeout on every request from the same client but we'd want to avoid updating the cache on every request (it could be hundreds/sec).
Any suggestions? Has anyone implemented anything similar to this on Azure. Any feedback would be greatly appreciated.
P.S. It's not only authentication that would happen on the server, but also custom authorization for each client. (Some client might have access to some functions, and others might not).
Thanks!
I'm in the middle of implementing something directly similar to this, but using OAuth 2.0 as the authentication architecture through ACS.
The model I'm following is shamelessly stolen copied from an MSDN sample here: https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417. This assumes the client has a user interface, so the user can present some kind of username and password either directly or through some third-party identity provider.
The advantage of this approach is that the WCF layer doesn't need to use any kind of session state, so there's no tedious mucking about with machine keys or whatnot. You'll still get something that can be mapped to an IPrincipal, however, so if you want you can create a custom RoleProvider and use declarative roles in the usual way.
Note the sample uses old-school ASP.NET, and has a dependency on an opaque (and possibly rather buggy) assembly Microsoft.IdentityModel.Protocols.Oauth. And, unless I'm missing something, I've not seen this released anywhere else (e.g. as part of Windows Identity Foundation) so I suspect it's rather new.
An alternative approach could again be to use ACS, this time to authenticate a SAML token, again following the OAuth 2.0 protocols. Details and sample code is here: http://msdn.microsoft.com/en-us/library/windowsazure/hh127795.aspx. That may be better suited to a system with no UI.
I have a WCF web service application built and tested on IIS7. Regarding authentication I wanted to implement a sql server hosted userd id and password authentication for consumers accessing the operations in the web service. However I was told that my company policy dictates that I implement SAML into my web service. That means any client that is accessing my web service operations need to be authenticated using SAML 2.0. I am not familiar with SAML but like to know and get started on how to implement it within my web serivice. I keep hearing two terms - Service Provider and Identity Provider, based on definitions on the web, I am assuming the service provider is my web service. identity provider is where the user authenticates to and the identity provider provides a assertion to my web service and then I let the client access the operations. I understand the theory but not sure how to put into practical implementation. Clients accessing my web service are not internal , i.e. they are external (extranet clients), so in this case what will be the identity provider and how do I add code to my web serice to make it a service provider?
I hope you understand my dilemma, can anyone explain the approach I need to take and any samples or tutorials that help me complete the web service is greatly appreciated.
I think SAML 2.0 is not provided by standard WCF. To make it work you must combine WCF with WIF (Windows identity foundation). Here you have very complex example of usage WCF with WIF and claim based authorization. The example uses SAML 1.1 but it is only configuration change to make it work with SAML 2.0.
Your problem is generally called Federated authentication or Federated identity where user authenticates against STS (service token service) and it receives security token (it can be for example SAML token). Than the client calls real service (RP - relaying party) where it passes its security token. So what are you going to build? If your company policy demands SAML usage they most probably already have STS and you just need to authenticate clients by SAML tokens as mentioned in the article.
Since 2011, support for Claims-Aware WCF Services has apparently improved with the release of .NET 4.5. I'll copy info from that article in case it ever changes, but as of the time of this answer, the process appeared to be as simple as:
Adding a reference to WIF (Microsoft.IdentityModel.dll) in your WCF Service project. Since this is delivered with .NET 4.5, I do not believe a NuGet package is necessary.
Use the following code sample to create a self-hosted Claims-Aware service:
var host = new ServiceHost(typeof(ClaimsAwareWebService), new Uri("myUri"));
FederatedServiceCredentials.ConfigureServiceHost(host);
host.Open();
Set your WCF service to use the federatedServiceHostConfiguration Behavior Extension.
I am currently working on a project that has an iPad application that uses JSON to call WCF services hosted with IIS. One of the requirements is that the WCF services needs to use IIS Basic Authentication to login. Once the user has been authenticated from the database, a few values need to set to a cookie for return trips to other WCF functions (similar to asp.net session variables). Is this possible with WCF and using cookies to hold state? If not, any recommended method?
Thank you.
WCF absolutely supports basic authentication. http://msdn.microsoft.com/en-us/library/ms733775.aspx has details on this. WCF will then identify this user on all messages that come through.
If you want to implement a customer authorization mechanic, you will need to implement ServiceAuthorizationManager. I've recently done something similar where I have iOS clients that use OAuth to authenticate with our services. I have this implemented a ServiceAuthorizationManager to determine who they are and what privileges that they have. Might be worth looking into.
Basic question here (I think), I was hoping someone could point me in the right direction. I don't know much about WCF but I'd like to create a web service to be called from an ASP.Net MVC application. The goal is to make sure only authorized ASP.Net users (we're using forms authentication) can call the web service, not just anyone. Are there tutorials out there I can look at on how to approach this? Many thanks.
I assume from the question that you don't care what the end (MVC) user ID is that is hitting the WCF service (in other words you don't need a specific authenticated user to hit the WCF so you can get the ID of that specific user (i.e. so you know that joeBobUser hit the WCF)). you just want to make sure that user is authenticated and authorized to use the site. You don't need every potential user of your MVC app to be authenticated/authorized.
As long as that is true, then my approach would be as follows:
run your MVC app as a specific, known user account (i.e. set up the app pool in IIS to runas a domain user such as yourdomain\youMvcAccount) instead of the default asp account. There are lots sites that have instructions on how to make this happen if you are not already running your mvc app as a domain user.
set up your WCF service endpoint configuration binding as WsHttp. Again, many sites describe how to do this. here's one that does it via GUI (I prefer hand-editing the config but whatever). So now your WCF service will only accept secure, authenticated requests
create your WCF client proxy in the MVC app. easiest way to do this (probably not best re: separation of concerns, but just to get started) is just add new web service and discover you WCF endpoint that way. Again, basic stuff easily googable if you don't know how to do that.
Now your MVC app will be making the call to the WCF service authenticated. However, at this point, any client authenticated in your domain can call the service. You are now accepting ONLY authenticated but ANY authorized user. All calls issued from your MVC app hitting the WCF will be from the identity yourDomain\yourMvcApp
Restrict authorization to the identity set in #1 restricting (authorizing) authenticated users can be done a number of ways. The get'r'done fast way (but not very flexible as any change requires recompile) is just to check the identity of the request is the same as the identity of your WCF service directly in your service call. Alternatively, you can set up more robust (with the concurrently more goo) options such as AzMan or other WCF authentication rule sets. Again, many sites have instructions on setting that sort of thing up after you have an authenticated user. Here is a SO question that limits authorization to a windows group post (I'd do it that way--more flexible but you need to add that user to a group on your domain), and another article that goes more into the details of WCF security and allowing only a specific user access to the service.