Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Web applications authentication and databases
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Fri Feb 08, 2013 5:03 pm    Post subject: Web applications authentication and databases Reply with quote

Hi all.

As many systems already have a network-based authentication mechanism such as Active directory or LDAP, my goal is to stop creating user accounts, one for each application. Many systems have their own list of users, which rarely interoperate. You can have for instance an ERP (Bahn, SAP...), a CRM (e.g. Dynamics AX), a document management system (Vivaldi, KnowledgeTree, Alfresco), a VoIP telephone system (e.g. Asterisk) and a messaging server like Lotus Domino 7, a monitoring application (e.g. Nagios), an inventory application (e.g. OCS/GLPI), all of which require authentication but you end up creating the same user accounts on all those systems (especially when outsourcing the implementation). When you're lucky one of these systems can import from Active Directory or LDAP. But the problem is the same: user accounts being replicated or imported n times all overt the place.

So, one problem at a time. I was wondering about enhancing database authentication for web interfaces. Currently most database-oriented web applications use an account with high privileges to connect to the database and user credentials, even though asked through SSL, often result in comparing the supplied credentials with those stored in the database. So what about reusing the credentials provided by the user?

The context is: credentials are always to be sent over SSL and sessions (if any) will always use SSL. With the idea of taking only the minimal amount of risks for every operation I have thought of the following possibilities:
  • ask credentials through HTTP authentication mechanism (basic, digest) either
    • through the web server's authentication modules or
    • what I'd call “programmed” HTTP authentication using server-side routines;
  • provide an authentication page: authentication is entirely done by server-side routines;
  • client-side certificates and private-key encryption using a passphrase;
  • Kerberos (client-side).
Reusing credentials allows using database engines' USER() variable, which refer to the account the current database connection is authenticated with. Nice when you want to track changes and who did what without sticking an additional parameter to every single modifying function or stored procedure.

Client-side certificates with encrypted private key also are nice if used with local keystore, such as seahorse or the one found on MacOS. But then server-side scripts may not authenticate users against the database database and the same account must be used for database connections regardless of whom the web application has authenticated.

OTOH one major drawback I find using HTTP-auth. mechanism is sending credentials each time there is a database operation server-side. Even if modern browsers are able to cache credentials locally that won't prevent these credentials from being sent over the wire. I fear each time credentials are sent even over SSL makes it one more opportunity to break into the system. Does that fear make sense?

As for Kerberos, not every browser has Kerberos built-in, right? Also I don't know how well (or not) it scales outside a corporate network.

What are your thoughts on that, people?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
dalu
Guru
Guru


Joined: 20 Jan 2003
Posts: 529

PostPosted: Tue Mar 05, 2013 3:13 am    Post subject: Reply with quote

So you want to create users with different privileges to a database? Am I reading this right?

Let's take a traditional mysql database most web apps use.
Your app needs read access to the database tables. Why would you want to create a single database user for every user that has access to this database?

What exactly are you trying to achieve and why are you complicating things?

- You want a "global" database with a user table and a session storage table.

What has to be encrypted?
Why does it need to be encrypted?

In the web world there are basically 3 types of storage.
(pseudocode)
- local static
e.g.
Code:

class user
{
    private $username = "user";
    private $password = "bzipped sha512 password or plaintext";
    private $salt = "random text to use with the sha512 algo"
}


- database
same as above but fetched and stored in a database table
does it matter which database you pick?

- oauth and openid aka sso
same as above but you send and receive data through a remote api and create database user from the results or deny access

you want an encrypted connection using the http protocol, it's a web app right?
so configure your web server to use a ssl certificate and key.

you could create chaining user provider aka checks all your databases if a user with provided credentials exists.

Not sure what you're trying to achieve.
Back to top
View user's profile Send private message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Tue Mar 05, 2013 9:24 am    Post subject: Reply with quote

Thanks for your lights, dalu.

I'm actually not trying to do nor achieve anything right now. I'm rather trying to understand how — in the various amounts of applications a company like the one I'm working in — it is possible to reduce the authentication overhead and password fatigue, mostly. I've been noticing for years every single application or system that becomes slightly complex comes with its own authentication system and we often end up re-creating the same user accounts all over the place. There are indeed SSO's but most applications I know of or have seen are not designed nor meant to work with an SSO. "Sharing" often becomes "Synchronizing copies". Poor design, lazy coders, whatever... go figure. This is not my conception.

So whenever *I* am involved, my goal is to break from that tradition and reuse as many existing components as possible. Databases and operating systems, for instance, do have their own authentication mechanism. What do we see? A table with user accounts and tables with permissions and authorizations... Reinventing the wheel. Database systems are so sophisticated they embed authentication and authorization mechanisms, such as permissions on columns or whatnot. Most commonly DB-based applications reinvent the wheel and re-implement authentication and authorization... with flaws.

What's the difference, for instance, between maintaining a table with user accounts, tables with authorizations (with all that code to manage) and creating system accounts with their own permissions and letting the database system manage them all? Requires root access on the DB? Yes, for managing accounts only. Most of the applications I've seen run with the full-privilege user even though the application only allows the person using it to read data...

My intention is to delegate authentication and authorization mechanisms to the existing layers whenever possible. So in the case of a web application, reusing the underlying authentication subsystem implies transporting the password either in clear form or under a decipherable form to the web server. That would certainly not fit every single application on Earth but I'm sure there are many simple cases where such a scheme would perfectly fit, right?

I have created nothing yet. This is just a discussion I'd have liked to have on this very topic. I want to revisit with security in mind how traditional concepts are implemented. Just wanted to know if anybody had anything to share on this.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9507
Location: beyond the rim

PostPosted: Tue Mar 05, 2013 11:09 am    Post subject: Reply with quote

Generally you will run into some common problems when centralizing authentication:
- applications are meant to run in different environments which do not have a common authentication layer (different databases, different operating systems, ...), some may have an abstraction layer to support multiple auth backends
- applications need extra data in user objects, and decoupling that from authentication can be tricky if not supported out of the box
- applications can have vastly different security models involving different mixes of users, profiles, roles, groups and multiple other object types

LDAP could in theory handle it, but it's a mess to setup correctly as most applications would require their own scheme extensions and LDAP implementations being a somewhat fragile thing in my experience.

Also separate authentication systems can be seen as an additional security layer as each application is somewhat isolated. If everything runs on the same authentication database a problem with one application has a much higher chance to affect your entire network.

While reusing existing components is a good idea in general, if an application isn't designed that way the work involved to make it cooperate can be huge. If you're developing in-house applications it's of course a different story.
Back to top
View user's profile Send private message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Tue Mar 05, 2013 1:52 pm    Post subject: Reply with quote

Thank you very much Genone.

Genone wrote:
LDAP could in theory handle it, but it's a mess to setup correctly as most applications would require their own scheme extensions and LDAP implementations being a somewhat fragile thing in my experience.

As for LDAP, what do you mean fragile? Do you mean, for instance, LDAP has no intrinsic integrity enforcement mechanism (or not strong enough) which makes it vulnerable to inconsistencies? (At least that is the first idea that comes to my mind.)

Genone wrote:
Also separate authentication systems can be seen as an additional security layer as each application is somewhat isolated. If everything runs on the same authentication database a problem with one application has a much higher chance to affect your entire network.

I understand that. That possibility exists indeed in the case of Active Directory, for instance. However basic precautions involve setting up additional domain controllers. Has anyone attempted to replicate AD to an OpenLDAP (read-only) for local authentication, for instance? Is that common practice?

Genone wrote:
While reusing existing components is a good idea in general, if an application isn't designed that way the work involved to make it cooperate can be huge. If you're developing in-house applications it's of course a different story.

The latter case is exactly the scope of my interests. Your thoughts?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Tue Mar 05, 2013 3:53 pm    Post subject: Reply with quote

I think a lot of this discussion can be helped by googling "one login" or "single sign-on" or "common login".

My employer makes applications which require authentication. In the past we have implemented one login like this:


  1. Use an LDAP query to hit the Active Directory server.
  2. The query checks to see if the user is a member of a certain group.
  3. The query uses the user's account and password to connect to the server, not a common configured password.
  4. If the query is successful, the user can log in. Otherwise not.
  5. Once that query is over, the local user account on our system is matched by login name.
  6. Local security settings for that account are used from that point forward.


In my case, there are literally hundreds of security settings being used by the software we write. Doing that correctly on an LDAP server would be insane. I know a lot of other large apps have a lot of specific settings too, and there's no way anyone would want to try to duplicate what might change on the next software upgrade anyway.

So IMO a common login service which is cross platform and secure with basic group management would be great, but you need to be careful where you draw the line in the sand. There will always be a need for some apps to manage at least part of their own security.

Some web applications allow for external security, and in some cases are wired so you could theoretically stick your own external module in there and rewire it in the config file, but I think it would not be fun.
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9507
Location: beyond the rim

PostPosted: Tue Mar 05, 2013 3:57 pm    Post subject: Reply with quote

VinzC wrote:
Genone wrote:
LDAP could in theory handle it, but it's a mess to setup correctly as most applications would require their own scheme extensions and LDAP implementations being a somewhat fragile thing in my experience.

As for LDAP, what do you mean fragile? Do you mean, for instance, LDAP has no intrinsic integrity enforcement mechanism (or not strong enough) which makes it vulnerable to inconsistencies? (At least that is the first idea that comes to my mind.)

No, I meant that implementations are very sensitive to minor details, e.g. crashing or otherwise failing with little or no useful information. Mind my (non-professional) experience with LDAP stuff is somewhat dated so could be better these days.

Quote:
I understand that. That possibility exists indeed in the case of Active Directory, for instance. However basic precautions involve setting up additional domain controllers. Has anyone attempted to replicate AD to an OpenLDAP (read-only) for local authentication, for instance? Is that common practice?

No idea, I've never touched anything involving AD. Though maybe the Samba4 LDAP server is of interest to you, as it's supposed to replace an AD server.

Quote:
Genone wrote:
While reusing existing components is a good idea in general, if an application isn't designed that way the work involved to make it coop[qerate can be huge. If you're developing in-house applications it's of course a different story.

The latter case is exactly the scope of my interests. Your thoughts?

First see above about security models and portability. Define the actual requirements your application has for authentication, then compare those to your available authentication providers. Try to not lock yourself too much into specific protocols if you're after a generic solution, use existing frameworks where reasonably possible. Try to not stray too much from established standards in your company, a superior solution is useless if ignored/hated by users.
All generic stuff I know, but in-house development is about what your company needs/accepts/provides, and that is impossible to say from the outside, so providing technical suggestions is out of scope.
Back to top
View user's profile Send private message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Tue Mar 05, 2013 8:13 pm    Post subject: Reply with quote

Genone wrote:
Try to not stray too much from established standards [...]

ROTFLMAO

(Sorry, that is absolutely *not* directed at you.)

Genone wrote:
[...]a superior solution is useless if ignored/hated by users.

Well, they're already ranting for various justified reasons in fact... *sighs*

Ok, it's not that there's no standard (although I sometimes wonder) it's just that there's no consistency. But that's another story and I don't want to get into details. You'd laugh though, I promise.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 06, 2013 3:55 am    Post subject: Reply with quote

VinzC wrote:
Well, they're already ranting for various justified reasons in fact... *sighs*

Ok, it's not that there's no standard (although I sometimes wonder) it's just that there's no consistency. But that's another story and I don't want to get into details. You'd laugh though, I promise.


This is a grand unification theory discussion.

From the outside, it's common to join a few schemes to make a unified authentication scheme for an office. For example, joining Mac and Windows, or Linux and Windows, or whatever.

The problem is, the more you try to tie into it the more difficult the problem gets. Yes, you could continue to throw time and money at it and eventually make it go, but the more complicated any system gets the more chance a single failure can take everything down, or that a minor failure will ALWAYS have PART of the system down.

As far as standards go, one size does not fit all. Software designers look at the available options and choose the one that works best for them, and then work with it to make it fit their needs. By definition, you wind up with some crazy diversity.
Back to top
View user's profile Send private message
dalu
Guru
Guru


Joined: 20 Jan 2003
Posts: 529

PostPosted: Sat Mar 23, 2013 7:30 pm    Post subject: Reply with quote

But still one might try to create a user entity that fits all needs.

If you have a prototype/struct/class w/e that fits all needs all you need is a storage layer to CRUD (create read update delete) the user.

In oop we have interfaces, very useful. And since I'm a php guy there are also traits now (idk what they're called in other languages, probably the same). A php trait is basically a template of class variables.

So I'm thinking...

Have a class and interfaces and traits
The class is a "template container"

So let's say you need to user to be able to interact with the basic linux system user and your local database and facebook and twitter.

You could say
class User implements LinuxSystemUserInterface, LocalUserInterface, FacebookUserInterface, TwitterUserInterface, \Serializable (to serialize and unserialize to and from the session)

(feel free to extend)

Now what are the most basic needs of a user entity?

UserId
Username
Password
(depending on your implementation also salt, but assuming we use mcrypt there's no need for an extra field)

What are extenend base needs of a user entity?

Email
(Email is sometimes used as an unique identifier, Twitter however doesn't send a user's email address, but we need to communicate with the user somehow outside of our application)

Time based needs?

CreatedAt
(When the user account was created)
UpdatedAt
(When was the last time the user information was updated)
LastLogin
(When was the last time the user logged in?)

Account status needs?
Enabled
(Is the user permitted to log in?)
Validated
(Is the account validated?)
(Usually Emailvalidation is used, there are also other means like SMS validation, we could split that into a field for each type of validation)
ValidationToken
(I feel it belongs here)
DisabledUntil
(If Enabled == false how long is it disabled?)
ChangePassword
(Does the user need to change its password?)
StatusText
(Let's say a user's account is disabled, let it know why. [ 'banned','tempbanned','spammer','needs validation','password expired','subscription expired'...])

Facebook needs?
FacebookUId

Twitter needs?
TwitterUId

Linux System User needs?
HomeDir
Shell
LinuxUID
Group
GID

---

Feel free to extend.

Now we can check if the user entity is of a certain type by checking the interface
if ($user instanceof LinuxSystemUserInterface)
// do Linux System User stuff
if ($user instanceof LocalUserInterface)
// do Local User stuff
if ($user instanceof FacebookUserInterface)
// do Facebook User stuff
if ($user instanceof TwitterUserInterface)
// do Twitter User stuff
Back to top
View user's profile Send private message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Sun Mar 24, 2013 4:13 pm    Post subject: Reply with quote

@dalu:

Thanks again. That sounds interesting. More or less the same kind of decoupling that I would have intuitively implemented.

1clue wrote:
This is a grand unification theory discussion.

Yes, indeed...

1clue wrote:
The problem is, the more you try to tie into it the more difficult the problem gets. Yes, you could continue to throw time and money at it and eventually make it go, but the more complicated any system gets the more chance a single failure can take everything down, or that a minor failure will ALWAYS have PART of the system down.

That's of course an inherent risk of centralized authentication, right? That's debatable but there are solutions to limit such impediments, like replication, redundancy... But I get to your point, I think.

1clue wrote:
As far as standards go, one size does not fit all. Software designers look at the available options and choose the one that works best for them, and then work with it to make it fit their needs. By definition, you wind up with some crazy diversity.

So if I get it right that's the job of the IT manager (or those who participate in the strategic decisions) to carefully select the products to limit that crazy diversity that finally plays against the whole infrastructure one day, right?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
dalu
Guru
Guru


Joined: 20 Jan 2003
Posts: 529

PostPosted: Sun Mar 24, 2013 9:13 pm    Post subject: Reply with quote

VinzC and all,
I'm currently writing a php framework that I'll release under the GPL (not sure yet which version)
and I'm trying to create a solid user entity and this is what I came up with,
so if you or anyone thinks this can be improved please go ahead.

I'll set up either redmine or a something else with a wiki and project management soon(tm).
I'd like to keep it as simple,intuitive and slim as possible.
I've been through 9 months worth of different frameworks and they're either overdesigned, not intuitive/getting in your way, poorly documented or missing features.
So far it only supports apache2, has routing, auth and firewall, yaml config files and uses doctrine2 and twig. (3.45 MB memory used with initialized doctrine2 and twig but I can save another 500k by rewriting symfony2's HttpFoundation. After all, all you need is a filter for GET POST FILES REQUEST COOKIE and so on)
After the user class and interfaces are done I'd like to focus on configuration by annotations, where appropriate and then write commonly used features like captcha, maybe even create branches for different needs like cms, social app, database app and so on. And all this work should flow back to the base framework, so if one would like to create a website with rss and pingbacks that uses jquery-ui and has social features and users uploading videos to youtube one would just have to create an instance of those components. So basically you have the base framework and pluggable components you can add by adding a line in composer and updating dependencies. That's the idea. No sneaky IOC containers just good old php.

Anyhow sorry for hijacking the thread ;) Go on.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Sun Mar 24, 2013 10:07 pm    Post subject: Reply with quote

VinzC wrote:
So if I get it right that's the job of the IT manager (or those who participate in the strategic decisions) to carefully select the products to limit that crazy diversity that finally plays against the whole infrastructure one day, right?


In part, but also the job of the software designer to determine what sort of application features it makes sense to tie to a unified network scheme.

For example, it makes no sense to have your windows Domain controller decide whether you have access to some button on a screen in your financial application, especially if that button only makes sense inside that application, and the setting has no meaning anywhere else in any business. You could add the user to a credit manager group using LDAP, and then inside your financial application you could make assumptions on that membership, or further fine tune access with an internal access control list.
Back to top
View user's profile Send private message
VinzC
Watchman
Watchman


Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood

PostPosted: Mon Mar 25, 2013 12:28 pm    Post subject: Reply with quote

@dalu: I'd be glad to review your code and to share my findings too. I also came to the same conclusion as for frameworks. I also many times had to re-invent my own wheel writing web apps for PHP and I've come with classes that I wanted generic (or generic-izeable) enough.

VinzC wrote:
So if I get it right that's the job of the IT manager (or those who participate in the strategic decisions) to carefully select the products to limit that crazy diversity that finally plays against the whole infrastructure one day, right?

1clue wrote:
In part, but also the job of the software designer to determine what sort of application features it makes sense to tie to a unified network scheme.

For example, it makes no sense to have your windows Domain controller decide whether you have access to some button on a screen in your financial application, especially if that button only makes sense inside that application, and the setting has no meaning anywhere else in any business. You could add the user to a credit manager group using LDAP, and then inside your financial application you could make assumptions on that membership, or further fine tune access with an internal access control list.

Ok, I see now. Authorization indeed makes no sense if stored globally when its context is application-local or if this application-local scheme is deployed for only a few users. My question however was only about identification and authentication, not authorization. So of course, what you say is perfectly right.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum