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.
Related
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.
I would like to use javaee security, but I need to authenticate users against an external proprietary authentication mechanism, which is different from LDAP and any other standard mechanisms coming with Wildfly. In particular, I would prefer if the authentication is taken care of by the application, not by the container. I only have come across PolicyConfiguration. But I think that it implies buiding an extension to be plugged into the underlying application server.
What I would like is to let application server obtain credentials in a standard javaee way, then execute a callback into the application in order to authorize them, and then establish current user together with his roles, so that I may use declarative security using annotations.
Is this possible in standard way? Or the only solution is to build an extension module for the application server?
An not so elegant solution would be to perform the login using HttpServlet.login. You still need to configure a realm that would acknowledge the username and password you provide in the method call.
Another, more complex, solution would be to create an JASPIC authentication provider. In short, you are in charge of the whole authentication process. Here is a collection of resources to get you started: Zeef
As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.
I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.
With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.
Is this approach sound?
If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.
Generally its no recommended to build one by yourself.
Store your users in a database table.
Authentication using other sites problems:
Your visitor may not want to have an account with 3rd party site.
It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).
In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).
We are developing a couple of web applications and web services for our intranet. To access resources like databases or other data sources we use technical domain users and store their credentials in the config file of the web apps. Passwords must be encrypted before written to the file. (The application then have to decrypts it to access the resources.)
We do this for quite a while but now a discussion came up. Our server operations team suddenly considers it unsecure to store the passwords in config files because an attacker might successfully decrypt it, maybe by analyzing the little tool used for encryption. (It's written in .Net so indeed it's not really hard to analyse the used algorithm by using Reflector & Co.)
As an alternative they proposed to use the technical user account as app pool security context. But I'm not sure if this doesn't mean to replace one possible security hole by an actual one: If the app pool runs under the context of the domain user, the attacker dont't have to know the password anymore. He simply can use security holes in the application or try to run his own code under this app pool somehow.
What do you mean? Is there a best practice to deal with passwords in web applications?
Thanks,
Rocko
Its a very common practice for a domain user to run the app. Just ensure that account has a really small footprint - only what is needed.
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.