I managed to setup windows authentication for my flask application with IIS 8.5. (Flask app runs frontend angular and also the api's needed by it). Everything works fine when i access the machine using the ip address and the port ie. the browser asks for a username and password prompt and api's work fine after authentication. But when I use the computersname.domain to access the page, there is no authentication and I'm automatically redirected(which I understand is auto-login because the requesting machine and the server are in the same domain).
The main problem is that when I use IP address to access the api's I was able to capture the username of the logged-on user using the flask variable request.environ['REMOTE_USER']. But when the computername and domain is used, I am not able to capture the username. How do I capture it?
Related
I have a scenario where I'm building an app that is hosted on an ubuntu server. Currently I have all inbound traffic to the server blocked with only outbound being allowed. The only way to access the React/Django app on the server is either thru VPN or having an IP whitelisted. When doing the OAuth1 process (to connect with a data provider), I'm struggling to figure out how to keep my app closed from the public internet but still complete the OAuth 1 process for the end user. Given that this app's purpose is to aggregate user data (from user's who've granted permission), it's not practical for me to whitelist the IP address of every single end user.
Currently, I'm considering making a form outside of my app for users to register with and then just having my app hourly check that form for new users so that it can then start the OAuth1 process and send the end user the authorization URL needed to grant permission to the data provider. At this point though, I have it where once the user signs up with their data provider, the callback URL redirects the user back to the Django app so that the Django app can grab the necessary elements from the URL in order to formally request for the user's actual access token. Given that the app is blocked to the public, I imagine the user won't actually be redirected back to the Django app for the access token part of the process to happen.
Any recommendations for this? For production?
AWS Cognito doesn't accept localhost as signin url. My app is hosted on S3 and behind a CloudFrnot distribution, so we can get https url. I'm using amazon-cognito-auth-js to do authentication on my app. Even if I run my app locally, after authentication, it will redirect me to my cloudfront url, and I need to check logs from Chrome developer tool. So for any change / test, I need to build my app, and upload it on S3, use a new inognito sesison on my browser. I'm wondering is there an easier way to do local development with Cognito? Is there any way to redirect Cognito to localhost and do local test there? Any other idea is welcomed.
Found the answer: you can add http://localhost:3000 as callback url (sign in) into your User Pool App client. You can either create a new app client for this purpose, or add a new callback url (comma separated) to existing app; each user pool client app can have multiple call back urls.
You can use localhost to test out cognito. The problem is that cognito doesn't allow HTTP. If you install an IIS certificate on you computer to use HTTPS on your machine, you will be able to use that as callback url. A tutorial for doing this is here
I am facing a problem understanding the reason why to use mod_auth_kerb for authentication to a Kerberos server.
I am developing a website using Django + mod_wsgi + Apache .
The first page of my website asks the user to enter username/password and one of my Django app will take the username/password and use Python kerberos module to authenticate the user to the kerberos server.
Where do I need to use mod_auth_kerb here ?
I understand that I will have the power to use the username/password to my advantage,is this the reason of using mod_auth_kerb ?
mod_auth_kerb can do two things:
Prompt the user for a username and password via HTTP Basic and validate them using Kerberos on the server side, or
Allow the browser to authenticate using Kerberos on both sides, via HTTP Negotiate. If the client supports Kerberos, this provides single-signon: the client automatically authenticates to the server via the Kerberos system without prompting for a password, via credentials obtained when the user logged in.
You are doing #1 in your application. It might be useful to move that into Apache, where it can be done once consistently for all apps. #2 you're not doing at all, but it's only useful in an environment in which Kerberos infrastructure is available.
A word of warning: I don't know about the "Python kerberos module," but it's very possible that it is not doing password validation securely. Many things which claim to do this do the equivalent of "kinit": they use the username and password to obtain an initial Kerberos credential (TGT), and claim success if it appears to work. The problem is that they have asked a third party (the Kerberos authentication server (key distribution center), or KDC) to validate the password -- but they have not checked that they are actually talking to a real KDC. They might just have received a message from the same user who gave them the password, and the message of course says, "the password is right." In order to do this properly the verifier needs its own identity in the Kerberos realm (a "principal"), and to take the extra step of using the TGT to obtain a ticket for itself and verifying it; this ensures that the reply is from a genuine KDC.
Another common way of doing this, if your KDCs are Windows domain controllers, is to use LDAP: connect to a domain controller via LDAP and authenticate with the password; the DC will check the password against Kerberos itself. Of course, you have the same problem: you need to verify that you're talking to a genuine domain controller -- but you can do that with TLS via certificates, which may be easier.
I'm developing a Django application. I need to authenticate users using Facebook and get the user's friends list to invite them to my site. To do this my application has to be registered with Facebook to get the API key. In the process of doing so I'm struck with the list of settings.
"http://localhost/login" --> this is the login page in my application where I have the Facebook-connect button
I need Facebook to redirect the response to "http://localhost/result", where I have a view to parse the result.
Please let me know how to configure Facebook.
Facebook can't redirect the response to 'localhost', as that's obviously local to your machine, hence the name. Your app needs to be somewhere Facebook's servers can actually see it - ie on a public host somewhere.
In other words, you can't develop and test a Facebook app completely on your local machine, as you would with a normal Django app. You'll need to upload it to your host at regular intervals to see any changes.
Alternately, you can set up port forwarding on your firewall/router to allow Facebook to retrieve directly from your localhost. The instructions for doing this vary greatly between different firewall/router manufacturers. What you need to do is open external port 80 and forward it to port 80 (or whatever port you have your HTTP server listening on) on the host machine where your app is, find your public IP address, and then use them as your callback address as follows:
http://<your.ip.here>:80/login
This will allow you to test your FB or FB-Connect app on localhost.
Case 1. When I browse a little test site from my own PC called JOHNXP (e.g. http://localhost/WebClient ), my .aspx page invokes my ASMX webservice picks up my credentials and passes them across to another webservice on ANOTHER machine (SERVERTRIM) in the same domain. I can see my request resulting in a Security Log entry on the SERVERTRIM machine with my credentials.
Case 2. I move to another PC in the same domain and logon with the same credentials I used back at my personal desktop. When I browse the same test site above (this time as http://johnxp/WebClient ), I get this percolated back to my .aspx page:
System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Net.WebException: The request failed with HTTP status 401: Unauthorized
Looking at the Security Log on SERVERTRIM, I note that the access in case 2 resulted in an ANONYMOUS LOGON which seems to explain the 401 / Unauthorized.
I'm trying to get my webservice to use the credentials of the logged in DOMAIN user when my WS calls a vendor's webservice on a different server.
My ASMX webservice runs on my desktop (IIS 5.1 WinXP Pro - machine name is JOHNXP). I have Enable anonymous UNCHECKED in every server involved and I have this in every web.config involved in my scenario:
The vendor webservice runs on SERVERTRIM (Win 2003 Server) and it is also ASMX and uses WSE 3.0.
Wireshark and Netmon look too formidable as tools for me right now. I am figuring the different resulting LOGONs on the "remote" server (SERVERTRIM) are sufficient "evidence". All machines above are in the same domain but I want to keep the "remote" webservice on SERVERTRIM and my intermediate webservice on a different server in the same domain if possible. Does this scenario demand that I have to dig into "delegation"? What would be the easiest tool to monitor why the same credentials result in an ANONYMOUS LOGON when the web request is initiated on another machine in the domain?
My knowledge of authentication is a bit hazy, but if I understood your description correctly:
in the first case, you're browsing to localhost, which is impersonating the caller, then calling a web service on a different machine. The impersonation is being done on the same machine as the client. I believe in this case, the impersonating application doesn't need to be on a machine that is trusted for delegation (because it's already the same machine as the client).
in the second case, you're browsing to a different PC, which is attempting to impersonate the caller when calling a third PC. In this case, the PC in the middle would need to be trusted for delegation (which it presumably won't be if it's a development workstation).