[dev] [horde] Horde as a Secure Document Delivery mechanism

[Kevin Myer]

Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Kevin Myer <kevin_myer at iu13.org>:
>
>> So my question would be, what would be needed, either within the Horde
>> Framework, or IMP, or both, to add something like a secure attachment
>> checkbox.
>> If checked, the document would require a username and password (which could
>> potentially be provided out of band to the third party).  What would
>> it take to
>> have linked attachments treated as an object, to which Horde
>> Permissions could
>> be assigned?  I somehow see a mix of Gollem, Horde, and IMP coming together
>> here - where a user could use Gollem to view their linked
>> attachments/documents, and could use IMP to send messages with links 
>> to those
>> attachments.  SSL would secure the transport, Gollem could be used 
>> to control
>> actual file permissions, and Horde provides the framework...
>
> It sounds like what you want is a way for people to create "drop
> boxes", sort of, though for downloading instead of uploading (though
> perhaps both), with custom (outside of Horde auth, and user
> controllable) user/pw settings on them. Either in Gollem, or as a
> seperate app.

Yes, thats pretty much the gist of it.  Whether it was intended to or not, the
gravy part from IMP is the part that already exists, mostly.  What I was
attempting to do was to take that one step further, and abstract the idea of
how files are accessed and stored, from any application, and rather than have
an application-specific VFS instance, let Gollem handle it all.  Then, if
you're dealing with a file share that you have permission to share with others
(this should be configurable by an administrator - I can see someone try to
share out one's organizational file server), you could treat files, or the
entire share itself, as an object that the user can define permissions 
for. There are a heck of a lot of things you can then do:  IMP linked 
attachments go
there, Ansel images go there, it can be used as a dropbox in a traditional
sense (Write only for Guests), sending an iTip meeting invite attachment from
Kronolith could also include a meeting agenda document attached in the mail
message body (which would then be accessible to users outside your Horde
install who might be invited to the meeting), etc.  I believe I saw 
support for
using Gollem in IMP for VFS storage, so I think this idea, in concept,
partially exists already, which is why I posted to the main Horde list.

The authentication part is maybe a little trickier.  You could require 
that all
users be Horde users, which you really don't want to do.  You could just use
Guest access for all non-Horde users, which you also really don't want to do,
because you're relying on security through obscurity, which amounts to a
pseudo-random link, which someone could easily copy and paste or observe
otherwise.

Or you could maybe create a new class of users, that are pseudo-Horde users,
which don't go through your normal authentication backend, but use the
equivalent of a horde_users table in a SQL database, keyed by Horde user.  So
User A can create permissions for Outside User A for File 1 and send a 
link and
User B can create permissions for Outside User A for File 2 and send a 
link and
they both can assign a different password.  When Outside User A attempts to
retrieve the file, the owner of the file is looked up, and that toggles which
user list in user_horde_users is used for credentials.  Of course, 
giving Horde
users the ability to arbitrarily create other users and give them permissions
to certain objects can be a very dangerous thing, so you'd have to be very
careful to minimize what these pseudo-users could actually do.

The way we've handled this for some of our non-Horde applications which have
"outside" users is to create a ficitious tree in our directory server
(ou=External).  If an outside user has an account in another tree of our
directory server (i.e. a user in one of the school districts we serve), 
we just
include their DN in the group membership and have some logic to switch LDAP
bases for authentication.  If a user is truly external to us, we create an
account for them in a new tree under the ficticious tree
(ou=People,ou=External).  That's authentication/storage backend 
specific (LDAP)
but its how we handle the need elsewhere, leveraging existing accounts as much
as possible and creating limited access pseudo-accounts if needed.

Don't even say "patch?".. :)

> The linking from IMP would really be gravy on top of that.
>
> Btw, Kevin, a bunch of your messages would probably be better suited to
> the dev list (dev at lists.horde.org) instead of this general list. :)

I'm never quite sure where a message should go :D  Perhaps a new feature for
IMP, configurable per domain and for list responses, that does heuristics on a
message's content and then flags the "dev-i-ness" of it? :)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org