User Store, Auth, VPN and Multi-user apps/software

[montie]

I seem to have hit a roadblock. I have read many posts, man pages, etc. and can't seem to put it all together. I wish to set-up a single system (since OpenBSD isn't too hungry on the hardware) for scalability upto 100 users (right now only 6 users) with same usernames and passwords across all apps.

Following is what I wish to do

User requirements
1) Wiki
2) Wordpress
3) CRM/Ticketing
4) Email

Servers, etc.
1) User Store
2) VPN
3) Authentication
4) Authorisation
5) SMTP/IMAP
6) Webmail
7) Self learning anti-spam
8) Antivirus
9) DB - SQLite
10) www - nginx, php5.3/5.4

Problem 1 -
Wiki, Wordpress are not a problem at all. There are 2 versions of wiki. One runs on local interface (assume 10.x.x.x port 80) and the other on public IP. The server is hosted outside on a VPS. Hence to access webapps on local interface, my users should be able to VPN into the server from a) Windows b) Mac c) iPhone, Blackberry 10. I have run into a lot of posts with people running a lot of software. I just don't know what to use. If someone can guide me to the correct grouping of various software, I'll read the documentation and figure it out. e.g. I don't know whether I'll need to run a DHCP, PPPoE in combo with pf for users to be able to connect into the local interface of the server.

Problem 2 -
Since usernames and passwords have to be common across apps, I know I have to use some form of LDAP (ldapd perhaps). What I don't know is what else do I need to run along with ldapd.

Problem 3 - Email
Glued solution (SMTP+IMAP+Amavis+SpamAssassin+Roundcube) vs Axigen?
OpenSMTPd vs Postfix?
Cyrus vs Dovecot vs Courier (lots of comparisons online, yet to make my mind up from the point of view of OpenBSD on IMAP server front)

[jggimi]

If you are looking for advice, mine is to eat this particular elephant a single bite at a time. Your specified requirements are wide ranging, and not necessarily clearly articulated. Here's what I can gather so far:

1. Single sign-on and identity management

Authentication requirements are application dependent. IF the applications permit external authentication services, and, IF the applications can all use the same service, your users will be able to use that authentication service with these applications. Whether that service is one of the BSD authentications (see the AUTHENTICATION section of the login.conf(5) man page) or can integrate with them, or can be integrated with LDAP, or is a third party authentication service you can integrate with your applications (such as Google or Facebook authentication services) -- these are application issues.

And, even if you find a common service ... will each application require its own authentication, or can an authentication can be shared between apps? Again, this will be an application-specific issue, based on the authentications it may have available. Since your applications are web-based, you should invest some quality time examining "Web Access Management" solutions.

Please note: if your applications require a Pluggable Authentication Module (PAM), you'll need a different OS. PAM is not available with OpenBSD.

2. VPN

I don't think you need one, based on the use-cases described in your post. Your applications are web-based. You should be able to deploy HTTPS and its encryption, and you can enforce HTTPS instead of HTTP to ensure private communications. With the addition of client certificates, you could include authentication of each user's browser before communication will be permitted to proceed.

If you determine that a VPN is needed, be aware that this is yet another layer of authentication that would be added -- and this is in conflict with your #1 operational priority -- simple userid/password authentication methods.

While IPSec can be deployed on all of the platforms you mentioned, implementations vary by platform, and you may find OpenVPN an easier cross-OS solution.

I'll repeat -- with the information you've provided so far, I don't see the requirement.

3. Email services

I hate to say "use anything you like" but I'm leaning in that direction. Years ago I used SpamAssassin and ClamAV mail filters (milters) with Sendmail. These days I'm using OpenSMTPd, but without any milters deployed at all, because my inbound mail comes through an MX forwarding service that runs DNSbls and other filtration services before mail reaches my MTA.

I'm currently using Roundcube as a web-based mail service. However, my deployment uses userid/password BSD authentication combined with client certificates on the browser, with enforced HTTPS. I'm not using any of their other authentication methods.

[montie]

Originally Posted by jggimi

Please note: if your applications require a Pluggable Authentication Module (PAM), you'll need a different OS. PAM is not available with OpenBSD.

Thank you jggimi

All my software is ldap "aware". I didn't even know something like a PAM or equivalent would be required. I gathered ldap would talk directly to the app via some kind of black magic. I guess, back to basics for me.

I am determined to make this work. Will post follow-ups for anyone who might be interested in something similar

I'm specifically not interested in running local apps over https only. The reason is - I don't understand technology and have a constant fear that some bot may still be able to crawl my webpages regardless of what goes into robots.txt. Over VPN or PPPoE, as long as the bot isn't connected to my local network, it won't be able to see my internal interface.

If I'm completely wrong, please feel free to direct criticism - I take it positively.

[jggimi]

Originally Posted by montie

I didn't even know something like a PAM or equivalent would be required.

It may not be. I only wanted to point out that if PAM is needed, you'll need to change either your OS or your app, or rethink your requirements.

I'm specifically not interested in running local apps over https only.

You'll need to define the term "local". You've described your environment as VPS, which is a cloud-based virtual machine, so *everything* is remote.

• Do you mean applications run from a shell?
• If so, are these text applications or are they X applications?

ssh(1) -- the Secure Shell -- can do both of these.

I don't understand technology and have a constant fear that some bot may still be able to crawl my webpages regardless of what goes into robots.txt.

Anything public, yes. Enforcing client certificates would privatize your web application(s).

Over VPN or PPPoE, as long as the bot isn't connected to my local network, it won't be able to see my internal interface.

That's the second time you've mentioned PPPoE. That's a network interface technology for authenticating an ISP customer with the ISP for switched connections -- it has nothing to do with privacy of communication, *other* than on the ISP's Ethernet segment (collision domain).

http://en.wikipedia.org/wiki/Point-t..._over_Ethernet

[montie]

Originally Posted by jggimi

You'll need to define the term "local". You've described your environment as VPS, which is a cloud-based virtual machine, so *everything* is remote.[LIST]

Apologies for the confusion. By local, I meant private i.e. on private IP (local IP) of the server on VPS. Antonym of public IP i.e. accessible from a public network. Since the VPN idea is constantly going on in the subconscious of my mind, I incorrectly expressed the private LAN IP of the server as local (similar to connecting onto a corporate intranet/LAN network)

I realise now that I may have assumed PPPoE incorrectly too. What I thought of was that it would be similar to "dialing in" to a computer (like 2 decades ago)

The only applications I use will be over the web as of now. Later, I may want to use something similar to OwnCloud/Pyd.io/Filecloud provided it talks to ldap as well (mentioning this as there may be a folder sync plugin which may not be over port 80/www)

[jggimi]

Originally Posted by montie

By local, I meant private i.e. on private IP (local IP) of the server on VPS. Antonym of public IP i.e. accessible from a public network.

I think you're going to have to be even more explicit. So far, you have defined an infrastructure that contains a single server. Without any additional information, this is the "picture" I can "draw":

{the Internet} - [VPS Server] - {private virtual console via the Internet}

If that picture is accurate, then "local" could mean one of three things:

1. The virtual console you use to manage the virtual server.
2. The loopback network interface for localhost connections (e.g. IPv4 address 127.0.0.1 or IPv6 address ::1)
3. TCP Sockets

Options 2 and 3 are similar -- both are internal to the OS and packets never transit a network. Privacy and security for Option 1, that virtual console, is a matter for you and your service provider. If you are using ssh(1) to reach that virtual console, or, if you are using a console applet within a browser that happens to use HTTPS to reach that virtual console, your session is encrypted in transit.

----

I have this additional advice: Try very, very hard to avoid using passwords for Internet facing applications. If you must use them, don't use them as the sole form of authentication, or require very complex passwords, enforced programmatically. Every Internet-facing application is under constant attack.

[montie]

There is no ssh. I do not require console access. I have console access over the web from the ISP (used to work with them/still do sometimes). They run VMWare Infrastructure.

The only applications in the truest sense are
1) Web based wikis (total 2) which me, my wife and a couple of external consultants would access using browsers on the phone/tablet/computer - Running on 10.0.0.1 or 192.168.0.1 on the server
2) Webmail - Running on public IP on the server
3) Email on mail clients (Computer/ Tablet/ Phone)
4) Some kind of system where we record our interactions with various people - Running on 10.0.0.1 or 192.168.0.1 or any other private IP address on the server
5) Publicly visible websites (2 nos)- Running on public IP on the server

Probably I'm unable to articulate this properly. I've attached a quick graphic.

-Montie

[jggimi]

OK, I've seen your graphic. Your connection to the virtual console is web based, as I assumed.

Now I have a question which your graphic does not answer: How do you reach the server at 10.0.0.1? The server is remote, and this address cannot be routed over the Internet. I'll make some wild guesses -- you pick which of these seems to be the best fit.

• I believe this is most likely:
  
  You don't connect to the VPS server at that address. It happens to have that address on its "internal" network. Your service provider gave you a pre-provisioned 10/8 network in the event you need multiple servers, should your usage grow.
• I believe this is less likely:
  
  You have a VPN already established between your local network and the VPS server. This could be a commercial SSL based VPN, such as Juniper Networks Remote Access, or OpenVPN, etc.
• I believe this is least likely:
  
  You have a gateway-gateway VPN in place, permitting flows between your local network and the VPS, and you route traffic to the VPS through it.

----

Assuming the most likely scenario -- a 10/8 network at the VPS with nothing but the VPS on it .-- you would have no "local" network traffic, because you have no other VPS servers provisioned. All of your intended services reside on the same server.

If you use that address to reach the server (as a user or as an administrator), please let me know which of my other guesses match.

If none of my guesses are correct, please try to explain more clearly how you connect to a remote VPS at the unroutable-on-the-Internet RFC 1918 address 10.0.0.1 from your local network.

[montie]

This keeps getting complicated. The 10.0.0.1 IP is what I intend to configure on my OpenBSD server on which I will have my private wiki running. I intend that my users will VPN into the server and be able to use those websites - as stated in the first post of mine.

To access the web console I enter a private IP on my browser URL (http://172.16.0.13). This is routed so that it is reachable from the 3 locations where I access the server console from. All 3 locations are being provided connectivity from the same ISP. The web console isn't just a console for only my OpenBSD server. It has a list of other servers which the ISP uses as well, to which I require access as I am consulting them for some systems of theirs. I just select the appropriate server from the list on the URL and get console access. None of the consoles are being accessed by anyone but me and the NOC Managers of the ISP (not even my users). I do not perceive a threat to my server from them.

As a fallback, in case I am not on the ISP provided network and I need to urgently access any of the consoles, I have to call up NOC support and they quickly patch an Internet connected cheap firewall to the same switch where the VPS resides onto which I VPN.

The specific reason I'm not using the ISP infrastructure for VPN for my OpenBSD VPS is because a few months down the line I intend to move my VPS out of there - or - I just don't wish to be reliant on 3rd party provided VPN solutions, they may not be able to add/remove/disable internal users of mine and I'll have to keep raising support tickets with the ISP for my users. Like you rightly said, I may not require VPN at all. I'm still reading up after getting inputs from your end. The list of articles is lengthy. I'm slow. It's taking a bit of time.

[jggimi]

Thank you for the additional clarification. Based upon what you've posted so far, I still do not perceive a VPN would be necessary. However, I only have what you've posted here as a basis for my comments. Its fairly clear I don't know a great deal about your intentions.

There are many different VPN implementations. Some may be configured to deploy a virtual subnet, which it appears you desire to have. Not all do this. OpenVPN can do this, which strengthens OpenVPN as a likely fit should a VPN be determined to be necessary.

In the event you deploy a VPN to permit access to your web applications, you would restrict your web applications to be accessible only by VPN users -- with or without "local" virtual IP addresses. This restriction can be done via web server or via packet filter -- VPN implementation specific, of course.

I now more clearly understand what you mean by "local" -- authenticated VPN connections. You mentioned above that that you wish to use unencrypted HTTP to communicate between client and server "locally". Be careful, if privacy is required for your applications.

If your VPN implementation includes a local virtual subnet, and if one VPN user's data should be kept private from other VPN users, test to ensure that no packets transiting between server and client #1 can be monitored or intercepted by client #2 on the same "local" subnet.

I understand OpenVPN can also use LDAP for authentication. However, my use of OpenVPN was decades ago, so I can't assist with any OpenVPN provisioning questions -- with or without LDAP access. I would guess that users would still need to authenticate at least twice -- once to connect to the VPN, and then one (or more) times to authenticate with your web applications.