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.
Related
I have a WPF application that uses Client Application Services to allow authentication (username/password logon) against a related web application that uses Forms authentication and the SqlMembershipProvider/SqlProfileProvider/SqlRoleProvider. This all works and I can reliably validate a user/password combination.
The WPF application also calls a number of WCF services that are exposed by the same web application as is used for the CAS authentication. I now want to be able to pass through the authentication details (from Client Application Services) to the WCF services in order that I can identify the user that was authenticated within those services. I also need to be able to prevent the WCF services from being used if no authentication has taken place.
I have found a couple of .NET 3.5 examples where CAS authentication is used against .asmx web services, or authentication is provided against WCF Data Services which does not use ClientBase and has authentication facilities built in, but I cannot find any examples with pure WCF. Can anybody point me toward instruction that will enable this scenario? I am using .NET 4.0 for this project.
I have also found this stackoverflow question but again this is answered for .asmx web services and not for WCF.
The closest I have gotten involves the creation of an OperationContextScope and then copying the cookie header from the ClientFormsIdentity object to an HttpRequestMessageProperty and adding this to the OutgoingMessageProperties of the current OperationContext. I then call one or more methods of the service within the lifespan of the OperationContextScope. Thing is, when I then get to the WCF service, I still cannot see anything that resembles authentication in such a way as I can identify the original user. This methodology has been taken from various examples but I am obviously missing a step at the WCF end.
I think you need to switch to the Web API that Microsoft is now having people use for WCF Services. Check out Using Forms Authentication with Web API and http://aamirposwal.blogspot.com/2012/05/aspnet-web-api-custom-authorize-and.html
Found it.
In my binding, I specified allowCookies="true".
According to Wiktor Zychla, "setting the AllowCookies property on a BasicHttpBinding to true turns on the automatic cookie management" - this means that any attempt to set a cookie in code will be ignored and this is what I was doing.
When i try to invoke a WCF service from an asp.net application (RP) which is authenticated by another asp.net application(IP) , I'm getting an error message with content of Login page (It is trying to reach the login page because it could not authenticate the request).
Identity Provider : _http://localhost/AuthenticatonWS/Login.aspx
Relying party Website : _http://localhost/RPWebsite/Default.aspx
WCF Service : _http://localhost/RPWebsite/Service1.svc
(In my solution I'm calling service1.svc from default.aspx.cs)
I don't want the service to be anonymous. Currently the site (RPWebsite) uses STS and trusts local Identity provider, but in production it can trust any external identity provider thru ADFS.
Can any one guide me how i can pass the token information to the service from aspx page, I did try several examples from internet but i could not get it working.
The problem could very well be that the RPWebsite uses ClaimsAuthorizationModule in <system><httpModules> or <system.webserver><modules> in web.config. This causes any web service call to be redirected to the STS for authentication, as if it were an interactive browser request, as you observed.
Alternatively, this module can be added in the WIF-specific section of web.config, that is, in <microsoft.identityModel><service>, and in this case this module is only used for claims-based WCF web service calls. You add it in the following form: <claimsAuthorizationManager type="MyNamespace.CustomClaimsAuthenticationManager, MyAssembly"/>. (This type must extend ClaimsAuthorizationManager, as described in the WIF documentation page "ClaimsAuthenticationManager, ClaimsAuthorizationManager, and OriginalIssuer".)
Reference: Vittorio Bertocci, "Programming WIF", p. 43.
I think there are several options:
Using Persistent Authentication Cookies that support multiple client sessions. Or support sharing session between your RP and WCF service, so that WCF can re-utilized the authentication cookies issued for RP when RP makes a call to WCF service. To be honest, I have never tried to implement this in action. It is just my theory.
Create an separate authentication service which require no user-interaction (such as entering username/password). And then you have plenty of way to call WCF from your RP:
From your RP, ask the authentication service to issue a token for WCF; attach the token into request header of WCF call (e.g.: Authorization); then call WCF service. This requires a custom HttpModule to accept custom request header containing token at WCF service.
From your RP, you can also store UserName/Password, or an unique user identity claim which could identify the user; attach those information into request header of WCF call (e.g.: Authorization); then call WCF service. This also requires custom HttpModule to accept custom request header at WCF service.
I would recommend the second option, which you could find more useful information and guideline from Dominick Baier's blog.
Just my 2 cents.
I have an Excel add-on which connects to a WCF endpoint located in our network to collect data. We're considering moving the application out to Windows Azure.
Currently the users are authenticated using their windows log on. I know that WIF, ACS and ADFS can allow us to authenticate on a web app but wondered if this would be possible with the WCF client.
Thanks
See here: Securing WCF Services with ACS
Also ACS and the code samples within.
If you are looking for delegation i.e. sign on using WIF and use that token for WCF, there's a delegation scenario and sample in the WIF SDK.
I need help on securing my WCF Service so that only authorized users can make a call to service methods.
The WCF Service is configured with wsHttpBinding and is hosted under Windows Service.
The client application is an asp.net website. Also, the users making call to WCF service are already authorized by client application, so just need to make sure that they are authorized while handling the request on service side.
Please guide me on what are the different ways (along with their pros and cons, if possible) to achive above.
Thank you!
If you are using the ASP.NET role provider infrastructure, you could pass the user on and leverage the same provider via WCF. This would be nice as it would maintain logic across the process boundaries.
If you are using Windows groups for ASP.NET, the same would apply, just re-authorize.
Certificates are an option, but then you have to manage them.
Lastly you could issue an access token and validate it on the WCF side. This could be done by extending WCF(probably at the contract level). You would then have to manage the token via some other service to enforce expiration etc.
The environment is in-house service based applications running in a Windows environment with WCF.
There are several "middle-tier" ASP.NET Web Applications and Web Services that authenticate the final client using Windows authentication, and use ASP.NET Roles to set Thread.CurrentPrincipal to a suitable RolePrincipal. These applications each run under their own service account, which is a domain account, and are considered to be trusted subsystems.
Some back-end WCF web services that may only be accessed by these trusted "middle-tier" applications. They use Windows Authentication to limit access to the service accounts used by these applications.
We now have a requirement for the back-end services to audit the identity of the final client whose call to the middle-tier application resulted in the call to the back-end service.
To avoid making any application changes, I was thinking of writing an endpoint behavior which inserts a SOAP Header with the final client's identity into the request sent to the back-end service. Note that the middle-tier applications are trusted, so no authentication of this SOAP Header would be required.
It occurred to me that this requirement may not be unique, so before I invent my own SOAP Header for this purpose I thought I'd ask if there exist any standards in this area I could reuse?
It sounds like you're after WCF Impersonation, check out the MSDN Link or Google that search term for more info. I've never used it myself so can't fully advise, but hopefully it's what you're after. Good luck
Edit: Does the WCF OperationContext not carry through the identity to the second phase? (OperationContext.Current.ServiceSecurityContext.PrimaryIdentity.Name)