We are using WCF services. Right now, we are using Windows Auth but this is not for long. Some services will sit outside the firewall and use username/password verified in the database.
My tech lead is "scared" at how easy any user can "Add Reference" to the services we have and just party on. He wants to "guard" the services by adding another identity - the application. He wants the service to accept requests from certain applications so the certain users cannot just use the service - add reference to it and call. It’s the notion of the application having an identity + credentials that is the operative principle here, as services on the network may need to authenticate those credentials prior to fulfilling a request, in order to prevent rogue code inside the network (i.e., NOT the application) from accessing services using “Joe User” end-user credentials.
Does this make any sense?
Then he believes the Juval Lowy's book has, in an Appendix that discusses sending more than one identity during a WCF call (Security Interceptor). There is no specific suggestion that all of those have to be end-user identities and if that is the case, one of those could be the identity of the application making the request.
How can this be done?
Thanks,
Sam
The problem with sending an application identity is that the secret used to confirm that identity has to be stored somewhere. If it is visible to one application on a machine then generally it will be visible to other applications running under the same identity.
Would your manager be happy with "it came from an authorised machine"? If that's the case you could simply use Client Certs
Its also worth taking a step back: if the user is authenticated and is authorized to perform the functionality they have requested, why do you care which application they came from - if they are who they say they are and they are allowed to do what they are requesting then why couldn't they use, say, fiddler to make the request - isn't that the point of a service (rather than a closely coupled client server app)?
You might want to look through Common Security Scenarios in the MSDN documentation to see if any of those options fit your needs.
The options that pops to my eye are Transport Security with Certificate Authentication and Message Security with Mutual Certificates. Both rely on X.509 certificates. The latter option is on the message level, so you can handle certificate delivery and security negotiation however you want.
To make it a lot harder for someone to add a reference to your service you could just remove the mex endpoint. This way it would be very difficult for a stranger to create a valid request message.
You can then distribute the WSDL manually, only to people you trust.
Related
I've been reading about WCF security for a whole day and can't say I'm comfortable with it.
I've developed some WCF services and deployed them to a test server and can call from a client. Both sides C# / VS 2010. The services are hosted under IIS 6. No option to go more recent at the moment.
So - I've read that I can only use HTTP with IIS 6 - which I believe restricts me to basicHttpBinding or wsHttpBinding as the binding.
I've also read that the XML sent over the wire using wsHttpBinding is encrypted, whereas basicHttpBinding is not.
So it looks like I want to go with wsHttpBinding as I will want some sort of authentication and I suppose user name / password will be passed along with the incoming messages.
First question is - if I use wsHttpBinding do clients have to call using https? And then do I need to worry about certificates etc. on the server?
Second question is - what security options are available to me? Do the callers have to be Windows users on the server, or can I make up my own user name / password and have that part of the service and the service do the validation and have nothing to do with Windows users? If I have to go with Windows users I suppose it's common to set up one user account on the server and have all callers use that?
The basic idea is I need to open this service to selected callers, but don't want just anyone to be able to discover the service and call it. I need to control somehow who calls the service. Is user name / password the standard way of doing this? Could I define a GUID for example which all callers would have to pass?
In answer to your first question. wsHttpBinding does not require HTTPS. You can use HTTP if you set the SecurityMode to Message or None. However, since you are proposing to send a username and password with the service calls you definately shouldn't do that. If you do then anyone will be able to look at the message in transit and read the username and password and your security is totally compromised. I'm afraid you will have to get a certificate and use HTTPS. It's not so bad though and there are lots of resources on the web to help you.
By the way, you can do HTTPS with basicHttpBinding aswell as wsHttpBinding. Also, you should consider using REST for simplicity. WCF has good support for it (webHttpBinding) and better support coming with the Web API.
In answer to your second questions, you do not need the callers to be Windows users on your server and you can use a username and password. This is called Basic Authentication. Again, there is lots about it on the web. Start here.
If you do this you will obviously have to have a database to store usernames and password so you can validate then and grant or denay access to your service. The simplest way to achieve this with WCF is to use one of the default membership providers.
I am working on a security component to use with an ESB for a client with very concrete high level requirements:
Integrate into an existing IWay service manager version 5.5 ESB (there is no security system in the existing set up).
Provide authentication and authorisation level information from source data stored in an existing active directory server used for another system (preferably using LDAP).
Authentication and authorisation should be performed in the ESB as the interface for the ESB will be exposed to both internal and external clients so total control over the client is not possible.
The client can not be relied up to have a certificate to allow bilateral SSL authentication, however unilateral authentication, where the client checks to see he is hitting the correct server is possible, so HTTPS connections can be established.
The service should sit on Weblogic (but I will be happy to take suggestions regardless)
Further information:
IWay ESB is a commercial, closed and fairly poor solution, in version 5.5 it provides no out of the box solution which fits the requirements. it is also stateless so no sessions can be maintained other than using a cookie or some method similar to store information.
Current ideas:
To implement a SSO service that is added to the messaging bus which provides a identity provider, service provider functionality, so an initial authentication will provide a token, which can then be stored by the client and passed with each subsequent request to be authenticated and an authorisation level passed (which i believe to be a fairly standard design pattern).
Research has been carried out on SSO + SAML implementation, openAM, Shibboleth, CAS all seem to provide a too complete solution which caters more for a portal type architecture (like CAS) or from a system where the initial SAML identity token is received from another sever altogether and then brought to the system (like googles implementation of SAML for some of its services).
I have also looked into JBossESB, openESB and service mix solutions which seem to use a bespoke implementation of SAML which can't be ported onto Weblogic and Zxid which has limited documentation.
It is a complex undertaking so I am expecting more high level architectural styles and library/project suggestions rather than complete solutions. I am under the impression that this should be a reasonably common requirement, a authentication and authorisation service for a ESB which uses a token system to prevent credentials having to be continually entered or stored in plain text but I am unable to find much information, what am I missing?
Any further questions I would be more than happy to elaborate.
It seems a solution using SAML is a valid solution for when users potentially/do require to access a third party service on an ESB but don't want the third party service to be aware of the security specifics of the ESB and the credentials information of the user. This way the ESB may provide a SAML token provider where the user can get the ticket and transport it to different services for authentication, the services then check back with the token for authentication and possible authorisation information (with SAML2 only). In addition to this SAML could be used like open ID where users are managed externally and users go to the external token provider to get SAML tickets.
This was a valid solution for us as the the client wanted to be very aware of the users accessing the ESB and there was to be no plan to access third party services as it was a completely closed system.
We subsequently implemented a more custom SAAS (security as a service) mechanism for internal authentication and authorisation inside the ESB (I know it sounds bad but with iWay there are limited options) using spring security libraries and the remember me functionality which in our case met the requirements.
Low and behold our clients then changed their requirements and asked for integration with share point. This did however simplify the security model in our system because we then designed of the following:
iWay's primary security model is based around SSL certificates, it is possible to implement an SSL Provider which will manage certificates, you should therefore be able to supply share point with your SSL certificate and iWay with the public certificate and secure up the channels between the 2 servers, you can then manage users within iWay who can access the ESB on a system level and specify a share point user even specifying it's ip, this information is sent in plain text but over SSL and in our case sent between servers in the same network.
We are then leaving it to share point to authenticate users on a finer level so access to applications is managed at the share point 'portal' level and the only thing the ESB is vaguely aware of is the authorisation information which is passed with the client SOAP message and defines to what level the services can be accessed (this information is used on a service level).
Downsides to this solution are:
For each new client application developed to access the ESB interfaces a new ESB user must be configured so it is not possible for clients to be developed which can freely consume certain services on the ESB.
New clients have to implement the authorisation logic so the correctly formated authorisation string can be sent and understood by services.
Other points:
I am aware that the newer version of iWay provides a LDAP adaptor which should be able to communicate with AD so you can have your LDAP server attached to the ESB through this way so it could possibly be consumed by another client or services in the ESB but you would have to customise share point to access the information through the iWay business provider.
I also believe iWay 6 provides a SAML token provider which you could utilize (going back to what I said previous about the use of SAML) but I don't believe this fits in with a share point solution.
I would like to share more ideas seen as we are both doing the same thing, can you find me through my twitter account which is specified in my blog?
We are currently working with iWay Server Manager 6.0.1 and are also having difficulties identifying HOW to handle security for web services within this tool.
We want to build web services with it that have AD security in them like if we were using .NET Web Services and haven't found a solution. Even discussing this with the iWay staff did not clear it in our minds.
Now we have to connect to SharePoint web services and the issue will definitely be there.
Have you progressed with your situation? We would like some feedback from people using the tool on how they actually implement security with iWay.
Sorry for the delay... been quite busy over here...
Basically we've done many tests between iWay and SharePoint and we are not able to set it up to sent the NTLM credentials required by SharePoint. We've tried setting up channels, proxies and various other solutions within the tool...
We've placed a call to them to hopefully get some help...
Pascal
Please suggest me the best authentication way to implement in the scenario mentioned below:
The requirement is I have to deploy a WCF web service in multiple countries across the world.
NOTE : All the machines on which the service is deployed are on the same domain.
1.The clients that access this service should fall in the same domain else the authentication should fail.
Currently I am using Message Security mode using "Windows"
I am curous why you would want the domain to be the same if it needs to be deployed in different countries around the world. Unless you are talking about hosting the service on an internal network that is not publicly exposed, enforcing the same domain name might be difficult. Different countries have different domain standards. America has a much richer set of domain roots to choose from. Other countries often have a country specific root, possibly with a regional subroot.
I would not couple your service to the domain that hosts it, nor would I recommend using the domain as a factor in authentication. If your service needs to be publicly exposed on the internet in each of these countries, I would recommend using something other than Windows security. A Claims-based security mechanism might work best. Internally inside the service implementation, claims can be checked, and if necessary, the windows identity can be authenticated separately from WCF authentication. Claims also allow you to utilize more than just a username/password or certificate to fully authenticate and authorize a client request. You can request the callers domain, country, region, and other evidence be included in the claim, allowing you to verify that calls are being made from the appropriate location and by the appropriate clients with much more flexibility than with Windows authentication (and if you publicly expose your service, Windows authentication will likely not be available anyway.)
Since you are running on an intranet and assuming that your Windows application will connect directly to the service, I would go with Transport Security using Windows authentication.
For some guidance consult patterns & practices Improving Web Services Security Guide.
I still question whether or not you need authorization. If you go with Windows authentication without any authorization it will simplify your service but will allow any domain user to access your service whether or not they are using the Windows application. Granted, they would have to have knowledge of the endpoint and the message structure but it would still be possible for them to do.
If Windows authentication is really all that is required, I would still raise the authorization issue and document it (and get sign off if applicable). On the one hand this covers you but also makes people explicitly aware of the decision and the possible risks.
I'm trying to understand how windows authentication / encryption works with the NetTcpBinding in WCF. I need to know exactly what encryption algorithm is used to encrypt the data going across the wire (and some documentation to prove it). Will windows authentication / encryption still work if the client and or host is not on a domain?
The netTcpBinding using Windows Credentials requires the caller and the service to be on the same domain - or at least on mutually trusting domains. Otherwise, the server won't be able to verify the Windows credentials and will refuse the service call.
As for encryption : you can even pick and choose which one you'd like ! :-) TripleDES, AES - you name it, with varying key lengths, too.
See the Fundamentals of WCF Security article - it talks about all aspects of security and encryption; also see the MSDN Docs on Securing Services which goes into some more detail; a good overview can be found here showing the properties of the basicHttp transport security element.
Last year I had to implement a distributed system using wcf that required a mechanism both safe and performant across all layers of the system. We decided for creating our own security architecture by creating a binary encrypted token. The encrypted token contained all permissions a given user had.
So for example a user would log in into the system and if successfully authenticated it would receive an encrypted token back. This token was stored locally on the web client. All further requests by the user would contain that token. The token was used in several levels of the architecture. The web server would use it to decide what visual elements to enable or disable. Since the service layer was exposed to the internet, each open door would check the token for authentication and check if that token had the proper permission to execute a given task. The business layer could check again for a more specific right included in the token.
The advantages:
It didn't matter if we were using NetTcpBinding or any other type of binding (and we did use more than one type of binding).
We saved a lot of round trips to the database
We could use the same token on different platforms
I know it probably doesn't answer your specific questions, but it will maybe give you some for food for thought while you're still deciding on the intra-layer architecture of your system.
WCF has a rich security model, I hope everyone can agree upon that as a given. I recently came across a situation where our client applications (WCF based applications that leverage the user's credentials within the domain) needed to communicate with services we had to deploy to a data center outside of our domain and control. Consequently, this broke our single sign-on model and I'd like know if any of you have had any success extending the security model to services beyond the domain.
Our identity model relies on the IIdentity and IPrincipal classes (not the WindowsIdentity/WindowsPrincipal) so using an alternative identity implementation is fine. As my question implies, I don't have an answer and I'm hoping you do. The one solution I have toyed around with requires the client to authenticate in our domain in the same fashion that they do now. As part of the authentication, they'd be provided with a X.509 certificate signed by our CA (which would be trusted by the data center). Certificates would be housed in a certificate store (I believe there is one that is bundled with .NET, but I'm unclear about it's ability to be leveraged in an environment where users move occasionally) and created/provided to the user when requested.
I'd appreciate any feedback and/or ideas.
Edit:
We have services that still reside within our data center in addition to the remote data center. I'd like to provide a solution that requires only a single signon (and fwiw, our users must enter their user name and password each and every time they launch this application).
If you have more or less point-to-point requests between few participants, like in a B2B environment, then certificates are definitely the way to go. Everything works automagically - once you've set it all up correctly, of course! :-)
Basically, your service will have a certificate to authenticate itself, and the client will also have a certificate which will be sent to the service and authenticates the clients against the service. On the server side, you'll be able to tap into the ServiceSecurityContext.Current.PrimaryIdentity to get access to the IIdentity of the caller.
For more information, see these resources:
Fundamentals of WCF Security - excellent intro
p&p WCF security scenarios
p&p WCF Security Guidance - very extensive, very complete
WCF Security - Barebones - Scenarios - excellent blog post series on scenario-driven WCF security
Declarative WCF Security - Juwal Lowy's fundamental article about declarative WCF Security
Hope this helps a bit!
Marc