I am making an web application that have to be integrated with other system using SOAP for communication between them. The problem is that I need to have users and store application specific information for them, but store the password on other system. So when the user enter his password username/password I have to make check on the other system and if this user exists and this is his password to log him in on my application.
So my question is how can this be done.
You have to write your own authentication backend!
Related
My workflow takes the user from a Django web application to a WooCommerce store. For example, they fill in example.com/register and are taken to store.com/checkout.
Both applications are backed by the same LDAP database, so at the moment I prompt the user to enter their credentials a second time.
This is functional, but not the greatest UX. How can I transport them from the Django to store domain and sign them into the store, without user intervention?
(Because the domains are different and I expect third-party cookies to be disabled, I obviously can't generate a cookie for the store domain while still in the Django domain.)
So I know it is really BAD PRACTICE to store a users password in cleartext (even encrypted)....But here is my problem.
I am developing an in-house automation web-app using django as my backend and users login using their LDAP credentials. My app interacts with several 3rd party applications (Jira, Jenkins, Gitlab) that also use ldap credentials for user authentication. I would also like the ability to write to the users (linux) file system from the server (saving generated scripts).
What are my options?
The only one i have though of is to encrypt the password when user logs in and store that in the django session. Encryption and decryption keys will be generated per session and saved using django's sessions. The password will be decrypted whenever a password is needed but it will never be saved as clear text
*Obviously the user will need to concent to this method
Any other ideas?
If we're saying about logging into user's account using SSH, you can use public/private keys to do that. When user logs in, use his password for connecting to his account and create here authorized_keys file (or edit existing one) inside ~/.ssh directory. That way you will have access to SSH later.
Additionally, you can create some scripts that will handle that filesystem changes on root level.
I know that Jira and Gitlab can use OAuth and I'm pretty sure Jenkins understands that also. So you might be able to generate an OAuth-Token for the user on login (when you have the password in cleartext) for those systems and then use that token without the need to store the password.
Regarding the SSH-Access #GwynBleidD already gave a good answer.
I am working on a Perl Dancer web application that needs to accomplish two things in terms of authentication:
authenticate users based on Active Directory for access to the application
authenticate as the user to access a couple of .NET web services.
The application is being hosted as a CGI application by Apache on a Linux box, and I do not have much control over Apache's configuration.
Below is the workflow of the currently working application:
Display a login page to the user
When the user submits the form, use Authen::Simple::ActiveDirectory to verify the account is valid
Store the user's credentials using Dancer::Session::Cookie (encrypted cookies)
Display a search form to the user
When the user submits this form, use Authen::NTLM and SOAP::Lite to access the .NET services (similar to the example here) to perform a search
Display the results to the user
The handling of user credentials here concerns me, but I am generally new to web applications and authentication. For a small internal application, is this okay? If not, how do you suggest I improve this process? Like I said, the application as outlined above works, but I feel like it could/should be improved.
One (part of a) solution could be that you let your apache webserver handle the
authentication. You could use Kerberos for this.
So only permitted users can access your application. In that
case $ENV{REMOTE_USER} contains the username (e.g. foo.bar#MY.DOMAIN.COM).
If you need more information about the current user you can query your LDAP (containd in your Domain). I use a common (LDAP) user to get more information about the current user foo.bar#MY.DOMAIN.COM.
I know that this is only the fist part. I do not have experience useing/passing Kerberos tickets by SOAP. But if you mange to handle this, you have a clean SSO solution.
HTH
We do this in the Apache config. It requires something like the below. You'll need a read only password-less user to bind to Active Directory.
AuthName "Active Directory"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPUrl ldap://server:389/OU=COMPANY,DC=COMPANY,DC=com?sAMAccountName,mail,name,extensionAttribute2,memberOf?base?(objectClass=user)
AuthzLDAPAuthoritative on
AuthLDAPBindDN "CN=ReadOnlyUser,OU=ServiceAccounts,OU=Users,OU=XXX,OU=COMPANY,DC=COMPANY,DC=com"
AuthLDAPGroupAttributeIsDN on
require valid-user
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.
I am working to set up SSO for our intranet the idea is that a user would login to their workstation using their active directory username and password. Then a small application would run at login that would send some uniquely identifiable information,user name, and computers MAC address to the server were it would be entered into a database with a time stamp. Then when the user accesses the intranet a java applet would send the users mac address to the server and compare it to the database entry to see if it finds a match within a given time frame, if it does then it signs the user in and removes the entry from the database.
Unfortunately our intranet is not running on IIS so I can't use NTLM to do authentication which would be easier but not cross browser compatible which is one of the requirements. NTLM is also not an option because our intranet is only accessible in the form intranet.company.com and as far as I know NTLM does not work with addresses in that form.
Okay now onto the question. I am currently in the process of creating the client authentication application in C++ and need a way to get some unique identifier or token that would differentiate a legitimately logged in Active Directory user from some one who got a hold of the application and changed their local username to an AD user.
Yes I know this is probably the wrong way of doing it but right now it seems like the only option. If you have any suggestions beyond not doing it please let me know. Also I am aware of the huge gaping security hole it creates if you can think of a way to patch up that hole with out NTLM be sure to let me know.
AD is just Microsoft's implementation of Kerberos. One of the core features if Kerberos is to create such permission tickets. So, on that side your solution is not a hack at all. It's just the validation part that looks like a car crash.
However, I'm entirely lost at the client-side problem you have. The entire point of AD or Kerberos in general is that you can't spoof an authenticated user. You just ask the OS for a ticket for the logged-in user. It doesn't matter who gets hold of your app, or or what his local username would be. The OS knows precisely who is logged in.