Apologies in advance for sounding naive but I am new to this and stuck since days to no good.
I have set up LDAP on apache web server using below link and it is working good.
https://httpd.apache.org/docs/2.4/mod/mod_ldap.html
I am able to login to the application using a valid account in the directory. Now I want to create a non-ldap user (common user for API access) that can be allowed access through the web server? Is it possible? How?
I would strongly advise to create API accounts in your Active Directory. (in the company I work for, we use that and call them service accounts)
Centralizing access is the best practice, if you start mixing authentication methods in your application/website it can quickly become a nightmare of spaghetti code to maintain.
Centralizing access also improves security by allowing you to manage access in a single place.
If you do not want to go this way, you have the possibility to create a secondary authentication method through local users that would be stored in a database.
If you go this way, please do not store passwords in a non-encrypted way. Look for the following functions: password_hash and password_verify. When using SQL to transact with your database, make sure you do not end up with SQL injection, it can be disastrous to have SQL Injection in your login script.
Related
I tried to do some research on this matter but couldn't really find anything. So, I was just wondering if anyone ever did something like this or if it would even make sense to do it that way:
Lets say, you have a secondary NAB for users who don't have a notes ID but need access to your web-enabled Notes / XPages applications.
Now, a non-notes web application wants to allow the same set of users access to their application.
Could this application use the Domino Web Login, so, user can log in into the non-notes web application?
How would a redirect work after a successful / failed log in attempt?
Would you use JSON / WebServices for that, or how would you implement it?
I know it is a rather general question, but I was just wondering.
Any response would be highly appreciated.
Thank you.
Daniel
If the other server can use LDAP for authentication, then you can configure Domino's LDAP task and set up Domino's Directory Assistance to expose your secondary address book to LDAP, and configure the other server to use the Domino LDAP as it's authentication source.
Note that this is not a single sign-on solution, so separate login will still be required for the non-Domino application. It does get you a single authentication source, though.
I am trying to find pros/cons of using ldap based authentication as opposed to application's internal database based authentication.
LDAP based
One situation I see is where a second application may directly authenticate against the ldap database created by the first application, using an ldap API.
Internal database based
In this case, the second application can perhaps do the authentication, if the first application has provided an interface such as a web service
The disadvantage I see that with ldap is that one more software component to manage. The disadvantage I see with the second case is that one has to write a web service to allow the authentication.
I would like to know what would be a good option, if one application may use another application's user database for authentication.
The main reason for using LDAP (or rather an implementation of LDAP) is to reuse existing directory infrastructure across an organisation. That is, many companies maintain a directory infrastructure describing their organisational units (OUs) and staff organisation within them - i.e. departments, staff, roles, etc. LDAP provides the interface to this directory service.
By managing your security through LDAP, you're in fact able to use this existing infrastructure and security/ roles information, rather than rolling your own. More significantly, this then maintains a single "id" per user, rather than an id in each system, thus enabling single-sign-on across systems. Also, LDAP supports SSL and TLS.
Rather than thinking of LDAP as having "one more software component to manage" as you said, you should think that rolling your own authentication in fact means you have one more user admin system to manage. That is, you need to build the admin tools to manage it (or do your sysadmins expect to use sqlplus or whatever?) Also, you seem to expect that other apps would use your shiny new authentication database when, they may also think "I'll roll my own".
All that said, it's not unreasonable to write your own security module but SSO is an often-asked-for requirement in large enterprises consisting of multiple systems.
Hi and thanks in advance,
I am looking for industry best practice or a ready made app to store and share passwords for for network resources.
My current situation is that I have a number of people that need to access applications as a specific superuser in order to access some features of these applications. The applications are third party build and cannot be changes to grant access to the required features for anyone but the superuser account. Normal admin accounts have elevated rights but things like creating accounts have to be done via the superuser account.
For security reasons I would like to periodically change the superuser accounts' password. Because of the number of people that need to be able to log in as superuser changing the password would be problematic and a logistical nightmare.
I'm looking to purchase or create an application that would:
Track who is looking up the password and to what resource
Allow me to specify what passwords a user can retrieve
The data should be stored and transmitted ultra securely
Preferable this would be an on-line application (I have Mac and Windows clients)
Keypass is great for this kind of thing. It provides a strong encrypted database of passwords and secure information. This can be accessed share via svn/dropbox/fileshare implementations using a master password.
This is more for a master database of secure data you can set up additional databases, maybe per user, but it starts to get a little away from what it's deigned for.
I would do a C# app that checks with a web service if the user can run the app and with what permissions, it would then be sent the encrypted credentials for a 1 time run, the service would log the request. This would all have to be done securely, so the service would use SSL and preferably certs between the systems. You have a good bit of research here to figure this all out, and you might have to use Java if you want mac... but I dont know how well that can launch apps as other users.
Solution #2 would be to use KeePass. You will have to be creative.
So I've read numerous articles on a password system for a web app, and they all seem very confusing. Some say you need to hash your PW's AND establish an https secure connection, others say you just need to hash AND salt your PW's.
I just know, after this has been done millions of times, there's PROBABLY some sort of library out there that can do a bunch of things for me for a password inputted on a client side, and give me something to save securely in my SQL Server 2008 database.
Do I need to worry about all the https secure connection stuff? Can I just make sure I hash the PW correctly? To hash it, do I need any external libraries or can I create a secure user/pw system entirely in .NET?
I've never done this before so any articles, tips, links would be very helpful. Thanks.
If you don't want to roll your own you can always use ASP.Net Membership
ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. You can use ASP.NET membership with ASP.NET forms authentication by using with the ASP.NET login controls to create a complete system for authenticating users.
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store.
Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET login controls to create a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting them . Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response.
Exposing a unique identification for authenticated users that you can use in your own applications and that also integrates with the ASP.NET personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to substitute your own code to manage membership and maintain membership data in a custom data store
Configuring an ASP.NET Application to Use Membership
There's also a project on github called Membership Starter Kit for MVC
The default MVC3 Internet Application template (file-new project) has this setup for you already, simply add [Authorize()] to the controllers/methods you want to protect. Don't roll something new, use what's there for you. In addition, please use SSL as someone can easily steal a session by sniffing traffic and simply using your cookie. It's that easy.
I'm working on the web app which will be hosted on the client's server.
There are various restrictions/security measures in place and I'm concerned that these can be "hacked" because the client will have a direct access to the ASP.Net user database through the SSMS.
I can think of few ways to stop the user from doing this, but I'm interested to find out whether there are any specific standards that I should follow?
If the client has direct administrative access to the database, there's not much you can do. If these are the client's login details - why is this then a problem?