We are developing a set of WCF Services for implementing the business logic in an application. The application using role based security for this application. The users are categorized in to different roles like Administrators , Managers , Employees etc. We want to ensure that users belonging to specific roles can only call specific methods. The WCF Services exposes a http based endpoint as well as a TCP based end point
We want to implement authentication using acess tokens. any help is appreciated
Regards
Sabarish
WCF data service doesn't support TCP endpoint - it can be exposed only through HTTP endpoint with webHttpBinding. Also I'm not sure how you want to apply standard role based security to data service resources. Check authorization section in this article.
It leads me to questions: Do you know the difference between WCF Service and WCF Data Service? What exactly are you using?
Related
Currently we run a UI web role and a web service web role(WCF REST) on Azure. Each role contains 2 instances (for load balancing and meeting the SLA reqs.)
The UI Web role and web service web role are within the same subscription but in different deployments. We do not want to merge the code bases (maintainability etc etc). So the UI layer is on xyz.cloudapp.net and the Web Service layer is on abc.cloudapp.net.
Currently, the requirement is to make the web service web role an internal endpoint i.e only accessible by the UI layer. The literature on configuring internal endpoints and accessing it from a different deployment is not very clear.
I am assuming that the two different roles need to be part of a single deployment for this to work. Can this be done without affecting the deployments? Any pointers in the right direction would be greatly appreciated.
Internal endpoints are only accessible within a single deployment, and do not route through the load balancer (so if you have 2 instances of your wcf services accessible on internal endpoint, you'd need to distribute calls between the instances). This, of course, would require you to put both your web role and wcf web role into the same deployment.
You might want to consider service bus for a secure way of reaching your wcf services from your web role instances. Or... expose the wcf services via input endpoint but secure the service.
There's an approach I like to call the virtual DMZ that sould meet your needs: http://brentdacodemonkey.wordpress.com/?s=virtual+dmz
It leverages the ACS and WCF bindings to allow you to create access control to input endpoints (which are then load balanced). Of course, if you don't want something tha robust, you can go with just a standard old WCF mutual auth scenario.
That said, David makes an excellent point. Internal endpoints are only accessible with a single deployed service. This is because that service represents an isolation boundary (think virtual lan branch) and the only input endpoints can be adressed from outside of that boundary.
Have you considered using ACS (Access Control Services) for restricting access using claims-based authentication to your WCF endpoint?
There are numerous protection schemes you could provide via WCF bindings.
Internal Endpoints can only communicate with inter-roles in the same deployment. If you have 2 separate deployments (abc.cloudapp.net and xyz.cloudapp.net, internal endpoints won't help you).
We write a WCF web service.
How can we call it's methods in JSON format?
An additional issue is how can we secure our web services.
I'd like to use Microsoft Membership and Roles providers for users authentication and authorization. The question is how to do this. Is it possible to do authentication and authorization behind-the-scenes (in context of WCF), or I must call ValidateUser() and IsUserInRole() in every web method for every user call?
Whether I restricted to use webHttpBinding (over wsHttpBinding) because our client-side programmer familiar with AJAX/JSON? Whether there are any restrictions of webHttpBinding concerning using Membership/Roles comparably comparably to wsHttpBinding?
Thanks a lot in advance!
Ilan.
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.
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)