I have published an orchestration as a WCF web service using WCF_WSHttp bindings. I think we about the SSL certificate working. It will be open to the internet, thus anyone who knows the URL could call it and pass data; so we want to add user/pass authentication. We simply one the one client/vendor to have the ability to call this webservice, no one else.
I've been reading everywhere, and cannot find any specific steps.
I think I want something like Scenario #4 here: https://seroter.wordpress.com/biztalk-and-wcf-part-ii-security-patterns/, but I cannot see how he got the "Client Credentials" box to pop-up in BT-2010.
Best I can tell is I have to:
1) In BizTalk Admin Console - set Security Mode to TransportWithMessageCredential.
2) From here: https://msdn.microsoft.com/en-us/library/bb226482.aspx, I'm a little confused about the difference between Windows and Username. An outside vendor is calling our webservice, so they are not on our domain. Do I need to set up a service account? Or can I just make up a username and insert it here somewhere?
3) Do I have to make corresponding changes to the WCF web.config that was created by the BT-2010 "WCF Servcie Publishing Wizard"
It seems like your're looking for just Basic authentication on the transport layer? All you then have to do is to create an AD user or a local user on the BizTalk machine and set the Transport client credential type to Basic.
Related
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
I have a system which will update some UI details regarding user notification every X seconds (just like StackOverflow's notification, gmail inbox and so on).
I am planing to have a webservice that will check for new notifications and have it called every X seconds. The fact is: I do not want to make it public for everyone, I want to make it accessible only to my system, so it is the only one able to consume it.
Is there any way to do that? Using a WebService is not required, if you have other approach I would like to hear it.
My system is built using ASP.NET 4.0 and Microsoft's MVC framework. Could I call an action to do that?
My question is similar to this: How do I secure ASP.NET web service to only allow relative path calling?
But as far as I understood the answer, he proposed that the webservice could be turned into an ordinary class method inside the system that is not accessible from outside. This does not work for me because I want to access it from the client side.
Thanks,
Oscar
ps: changing infrastructure configs (ex: hosting it in an internal server) would be hard to do...
EDIT: what I want to achieve with this webservice is to update the notifications number. This should be done without refreshing the page, for this reason I thought about verifying with the server if there are any notifications and, if there are, update the UI.
Edit2: I could transform this webmethod in an ordinary method inside my system, that would be no problem. The question would then change to How do I wire the client to this method? Maybe calling an action using javascript and then inside this action calling the method?
Deploy this WebService on a different web site and then configure this site to be accessible only from IP : 127.0.0.1. Also checkout this blog post - you could install the IP Security and then:
Lastly, to create the restrictions, open up the IIS Manager and select
the website that you want to restrict. Open the IP Address and Domain
Restrictions module, and then in the actions panel (on the right side)
choose Edit Feature Settings.... To only allow local browsing, you
should deny by default. Choose Deny from the dropdown, and hit OK.
Then add your exceptions -- the IP's or ranges that you want to allow
access to. To do that, choose Add Allow Entry... from the action
panel, and add all the exceptions you need.
Now, only applications running on the same web server can access this web service.
I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?
I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.
I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!
OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.
The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.
You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.
Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.
You can share credentials between the applications using ASP.NET Client Application Services.
Here are some resources:
Client Application Services
Client Application Services with Visual Studio 2008
Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.
I think its best idea to use a web browser control inside the desktop application .
Then use the WebBrowser1.Document most probably
WebBrowser1.Document.Cookie
get if the user is singed in.
I also need to make sure this URL that
is used cannot be simply copied and
used from another location, so I'll
need to include some sort of
information in the encrypted value to
know where it's coming from.
If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").
I'm getting a 401 (access denied) calling a method on an internal web service. I'm calling it from an ASP.NET page on our company intranet. I've checked all the configuration and it should be using integrated security with an account that has access to that service, but I'm trying to figure out how to confirm which account it's connecting under. Unfortunately I can't debug the code on the production network. In our dev environment everything is working fine. I know there has to be a difference in the settings, but I'm at a loss with where to start. Any recommendations?
Have you looked in the IIS logs?
I would also recommend looking in the Security event log on the server for authentication failures. You should find a footprint of the failed authorisation attempt here. Be warned though - it is not unusual to get 10s of security events a second, so ideally you need to be able to access the event log as the requests are failing.
If you do not specify which credentials to use in your ASP.NET page when you instantiate the web service then I believe it defaults to NT_Authority\Anonymous.
If you're using System.Net.CredentialCache then your web service needs to be in a trusted domain, accessed over HTTPS and using either NTLM, Kerberos or Digest Auth otherwise it does not pass the credentials from the cache.
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultnetworkcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
Perhaps the production server uses a different user for its application pool than your dev environment? I once spent a day figuring that one out. Another option would be the (lack of) impersonation in the web.config
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx