We are building our public facing website on Wordpress and on a Linux server. The user will be logging into the WordPress site with OAuth2. Our data and API is going to be built on an ASP.net MVC4 server. I have a couple of problems that I need to resolve and am trying to figure out the most secure way to Authenticate on the IIS server.
1. I need to authenticate with Wordpress.
2. I need to associate customer numbers to the login from 1 above.
3. Somehow I need to then be able to use that associated customer number and some for of Authentication to allow the IIS server to service the requested API.
Some thoughts were to store some kind of UUID for each customer number and store it on the WP and IIS server and then when the request comes in to IIS confirm that the passed UUID matches what was issued to the WP server in step 2 above. My concern is though that this UUID could be compromised/forged at a later time and that UUID could be used to make calls to the API on the IIS server.
What is the best way to implement security on the IIS server that allows the customer to login only on the Wordpress server?
I'm currently using a Custom Http Authentication Module in IIS, so when I need to consume the web api from WP, I follow this approach: I build petition with my custom authentication rules (example: you can use a custom http header, o something else to pass credentials), in web api side, I check credentials (using http authentication module, of course), if everything is fine, http authentication module allow requests, if not, It deny request.
Related
I have this legacy intranet app using an AngularJS SPA consuming an an ASP.NET Web API (on .NET 4.6.1) and I can't manage to get the user authenticated on the domain inside the API, when calls are made by AngularJs.
Inside the API I have situations where I need to get the domain authenticated user. I have tried several combinations inside IIS to set both the AngularJS app and the API with Windows authentication, Impersonation, Authorization Rules. I've read several questions in Stackoverflow and other forums and also searched through several articles but I can't manage to find a solution, I'm feeling helpless in this one.
When I make a direct call to the API using a tool like Postman or through Swagger, System.Web.HttpContext.Current.Request.LogonUserIdentity.Name shows the correct authenticated user.
When I make the very same call to the API but through the client, like loading a page that requests data from the API, the user shown in LogonUserIdentity, is the one set on the app pool.
The authentication between the client and the API uses bearer token.
Here's my current scenario:
IIS:
Windows authentication enabled for both the client and the API, Impersonation enabled for both the client and the API
Authorization rules for ASP.NET and IIS set with allow all users for both Client and API
Session state in-proc, using cookies and with UseHostingIdentity set to false on both Client and API
Both the client and the API are using the same AppPool, with integrated Pipeline, .NET CLR v4.0,
If there's more info to supply please let me know, I'll update the question with the required info.
Background
I want to create a PHP application that eventually will be installed on a "countless" web servers.
The application is going to access the Google Drive associated with the web server's administrator Google account (it will basically write some files on user's cloud storage). So my PHP app will be authorized by the end-user to use its Google Drive storage. This is done (via the OAuth2 protocol) by connecting the Google OAuth2 service.
So basically I have to create a ClientID/Secret pair (on behalf of my Google Account) that is gonna be used to execute the authorization flow.
Google provides 3 authorization methods:
for web applications (web browsers over network)
for service account (my server to Google server)
for installed application (like Android, IPhone)
(1) is perhaps the best choice EXCEPT that I have to define a REDIRECT_URI where the authorization code will be sent. Because my APP will be installed on a "countless" different servers I don't know in advance the protocol, domain name and the path (also the URI) where the Google's response should be returned. If I would install this application only on 3 servers I could create upfront a ClientID/Secret pair for each of them. It's not the case.
(2) means to deploy my P12 private key with the PHP application and I don't feel comfortable with that!
(3) means to put the end-user to copy/paste an authorization token from a Google web page into my application web interface. I am trying to avoid doing that.
I already made it to work by using the method 1 when I know in advance the REDIRECT_URI. I also embedded the client_id/secret pair in the source code so the whole authorization process is user-friendly. But this is not going to work on a "countless" deployment scenario.
Questions
Which method and how should I use it in order to make the whole process safe for me (as developer) and for the client too (the web server administrator). Note that the authorization process should not involve the end-user to copy paste some codes. I want that step to be transparent/user-friendly for the end-user (no one likes copy-paste when it can be done automatically).
Should I embed my client_id/secret into the application or that's totally wrong? I suppose no end-user wants to go through the creation of its own ClientID in Google Developer Console, right? On the other hand why I would give my client_id/secret to an unknown end-user?
Final thoughts
I could create a proxy application on my (the developer) web server such that my PHP application (which is supposed to be deployed "everywhere") will send the authorization request to my proxy server (which has already its own client_id/secret) which in turn will redirect the call to the Google OAuth service which then REDIRECT_URI back the authorization code to my proxy and finally I will redirect back the response to the original sender (the PHP application). What do you think?
Some useful answers here and here or here.
#Edit: as I've already said earlier a proxy would be a solution. I've made it and it works. The same solutions I've received also from user pinoyyid. Thanks for your answer too.
A proxy is the only real option open to you. You can encode the originator URL in the "state" parameter, so that when the proxy receives the access token, it can call a webhook at the originator.
There are some contradictions in your question...
"The application is going to access the Google Drive associated with the web server's administrator Google account" and "So my PHP app will be authorized by the end-user to use its Google Drive storage." are mutually exclusive.
If the Drive storage belongs to the app, then the user isn't involved in any OAuth dialogue.
Could you edit your question to be clear who is the owner of the Drive storage as it greatly influences the OAuth flows.
I have a bunch of websites that are setup identically to use a WIF identity provider. I've recently moved the business logic out of the web applications and into a Web Api service application. This runs in a different virtual directory to the other sites. The idea being that browser will put the data into the page AJAXy.
The issue I have is with securing the web API. It seems that WIF single sign-on works okay with traditional sites. The user can access one website, get redirected to the identity provider, login and get redirected back to the website they wanted. When they access another site they also get redirected back to the identity provider but needn't log in as a FEDAUTH cookie exists so they automatically get authenticated and redirected to the second site.
This doesn't work for the Web Api scenario because when the browser perhaps makes a GET to it, the Api will return a redirect to the calling javascript when it should be expecting JSON.
Is it even possible to secure Web Api with WIF?
Not sure whether I got you right, but it seems like the main problem is that javascript/ajax does not support http redirects.
A possible solution could be to simulate the redirection with a sequence of seperate calls in ajax:
Check whether you are authenticated on your web api site (by a dummy ajax call).
If this is not the case:
Call your sts over ajax and grab the security token out of the "wresult" form field.
Call the login site on your web api site and pass the security token as "wresult" data.
Dominick Bayer wrote a few blog posts about securing rest services. For further reading have a look at http://www.leastprivilege.com/. (Especially http://leastprivilege.com/2009/09/11/adding-a-rest-endpoint-to-a-wif-token-service/ and
http://leastprivilege.com/2010/05/05/thinktecture-identitymodel-wif-support-for-wcf-rest-services-and-odata/).
The following presentation from TechDays might also be interesting: http://www.microsoft.com/showcase/sv/se/details/ffc61019-9756-4175-adf4-7bdbc6dee400 (starting at about ~ 30 minutes).
HI have the following scenario:
1) i'm authenticated against some aSP.NET web site and my session time out expires in 24 hours.
2) after several time I would like to run query against asp.net Web Service located on the site using existing authentication.
What should I add to cookie Container? I how do sent existing cookie to Web service?
Thank you in Advance.
Danny.
A web service call is just an http call so it will come under the existing authentication.
I am assuming here that you are issuing this from the browser?
If not - e.g. if you are doing it from a console application, then you will have to interact with the site as if you were a user. Some more details are her http://www.ksingla.net/2006/08/sample_forms_authentication_test_in_csharp/
Basically you need to issue a post to login to the login page - track all of the cookies etc - and then start issuing your WS calls with those cookies.
Another option is here http://en.gli.sh/Blog/post/NET-Interoperability-Between-Smart-Client-and-Internet-Explorer-Using-Cookie-based-Authentication.aspx which is reading the correct cookie info from the windows machine you are on - relies on you being logged into the website and also trusted to be able to get to that file.
Alternatively you can look into implementing WSE or WCF solution.
My production environment involves a pair of IIS 6 web servers, one running legacy .NET 1.1 applications and the other running .NET 2.0 applications. We cannot install .NET 2.0 alongside 1.1 on the same machine because it is a tightly-regulated 'Validated System' and would present a bureaucratic nightmare to revalidate.
Websites on both servers use Basic Authentication against Active Directory user accounts.
Is it possible for a web application on the 1.1 server to securely redirect a user to a page served on the 2.0 server, without requiring users to re-authenticate?
No, because you're not using cookies for authentication in that scenario, so ScaleOvenStove's link won't help.
Basic authentication sends the login information in the HTTP headers with every request, but it's the browser that does this, when it sees a new server, new password request.
(Or indeed as suggested change the authentication on both systems to support single signon)
In order to achieve this you could implement a single sign-on solution.
This solution would have one server be your master authentication server. This server would be responsible for authentication and creating a cookie for the user. When you redirect to the other server (on the same domain) check to see if the authentication cookie exists that was created by the authentication server, and if it exists, and has valid data, auto login the user. Make sure that you set the domain on the forms authentication ticket and cookie, and then both servers which exist on the same domain will be able to access this cookie.
I would google single sign on asp.net. There's a number of ways to achieve it, but it's definitely achievable.
yes, check out here
http://weblogs.asp.net/scottgu/archive/2005/12/10/432851.aspx