new thoughts on security and mailbox structure

[acoliver]

Guys,

What do you think of this?

Mailbox support should be refactored such that folders look like this

joe/
inbox/
foo/
andy/
inbox/
spam/
foo-doo/

UserRepository will now need to support properties for users:
String user = "andy";
String password = "yeahright";
boolean b = ur.authenticate(user, password);
boolean b = ur.authorize(user, "andy-inbox-create");
String s = ur.defaultFolder(user);

(s.equals("andy/inbox") == true)

POP should be bound to defaultFolder. Default listeners will route SMTP mail to the defaultFolder.

Mailbox will need to change dramatically:
folders can contain other folders.
folders contain attributes:
create-roles
write-roles
delete-roles

roles are additive, meaning if andy/inbox has two roles for create-roles (andy-inbox-create, inbound-smtp-create) then users
having either role will be automatically able to create mails in that mail box.

UserRepository should have an "unauthenticatedUser" which has some default roles (inbound-smtp-create). SMTP should check this
user with no/any password when a user runs any supported command after HELO except for AUTH.

Any way we could do this using aspects or chains?

[mikezzz]

Perhaps annotated aspect to that contains a description the type of access to a folder (read, write). And an interface 'Securable' which has the methods for getting a list of roles for this object.

public class Folder implement Securable {

 @Secured (access="read")
 public void getMessage {...}
}

public class SecurityAspect {

 public void isAllowed() {
 Securable sc = (Securable) getCurrentObject();
 String access = metaData.get("access");
 if (sc.getRoleSet(access).retainAll(currentUser.getRoleSet()).size() > 0) {
 // Ok.
 }
 else {
 throw new SecurityException("Bad person doing bad things");
 }
 }
}

We would define a join point for Security Aspects to be bound to methods annotated with @Secured.

One of the things that I was thinking about related to folders is that it would be nice to be able to address any entity in JBMail using a path e.g. my inbox could be addressed as '/{domain}/mail/folders/mike/INBOX'. Mostly this would help REST and CalDAV should we decide to implement these and provide a uniform interface to any object in the system. Perhaps we could have the concept of "mounting" a module. It would require a common contract for all modules that contain entities. Just an idea, probably overkill.

[acoliver]

Ummm yes... I like the folder addressing scheme. I need to start thinking virtual hosts... I think I like the above aspect but idea... I mostly like it...I think... I dunno it seems like it is missing something but I can't put my finger on it.

So do we have to go to JDK 5 yet? I scheduled this for M5 in the jira stuff I'm trying to outline a formal plan... My mind says wait just a little longer....but my heart says "yumm...upgrades!"

I'm also salavating over something we should not do (the NIO threading thing....)...at least prototyping it....but I must ....resist....think...release schedule....important stuff first...

-Andy

[sunfire]

While you are working on the Mailbox design maybe you want to keep an eye down the road on features need by imap (and mybe other protocols). In addition to the more JBM internally used attributes you need to be able to attach a set of flexible (and client definded custom) flags to a folder (e.g. \Draft, \Seen, $Spam, etc.). Simplest way todo it would be to introduce a private hashmap to the mailbox and let every protocol have their own key to access their flag object in it and expose it like this:

Object getFlags(String key);
void setFlags(String key, Object flags);

NOTE: String may be prefered over Object and would certainly satisfy the needs for imap but since I have no idea if other protocols my need their own complex objects for flags...


It would also be a nice feature to add an event observer type of mechanism to mailboxes. Reason for that: an IMAP connections instance has opened a mailbox and is idleing in it with NOOPs/CHECKs. A second connections instance is accessing the same mailbox and expunges a few mails (could also a user in a webfrontend, a pop3 instance, other imap client, etc). The first connection now needs to be updated that mail # 3, 5 and 8 have been deleted. So to allow a protocol instance to subscribe in some way to certain mailbox events like DELETE or ADD would make things much easier. Else you need to either do a lot of dirty overhead in the protocol implementations and/or place locks on the mailboxes much longer then actually needed (or needed at all).

Cheers, Thorsten

[acoliver]

Very helpful good points. keep it coming!

For NOOP/Check, I'd like to use NIO and make hte connection go on a NOOP/Check pool. The tomcat guys did this with native stuff for keep alive with nice results!

The latter point I'm less sure of. Its a matter of transacitonal integrity. I'm not sure I like the volatile integrity this implies... My thought is that the Hibernate implemenation will be the default. We'll use versioning and optimistic locking...something goes awry the latter user gets an exception "no sucka you can't" or the IMAP equiv and his DB session is essentially reloaded or something. I'm not sure a notification scheme is safe or necessary or even permissible by IMAP (though I could be wrong).

[sunfire]

The IMAP RFC calls this kind of server-> client notifications "unitlateral notification" and you need them to keep the client and the server synchonized. Here the RFC text

Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages.

One of the reasons this needs to be done is that client and server need to be in sync for message sequence number(MSN). But lets talk about a simple case:

- mailbox contains 10 messages when connection 1 SELECTs the mailbox
- connection 1 NOOPs around for a while since the user just keeps his client open on his workstation
- now he also connects his laptop and for some reason opens up connection 2 that SELECTs the same mailbox
- he EXPUNGs the mail with MSN 3 on conn 2
- now by IMAP RFC the mailbox is required to reorders it MSNs and decrement all MSN > 3 by 1 after an EXPUNGE and all future references from the clients also need to be aware of the new MSNs
- if conn 1 is not notiefied that the number of mails in the mailbox changed and he deletes the same mail on his first client (MSN 3)... the server will happily acknowledge it and delete MSN 3... what happens to be the former MSN 4... *boom*

I am no IMAP expert by any means but this MSN reordering thingy is kinda tricky if you don't want to rely on the clients implementation to check for such things or don't want to totaly lock a mailbox as soon as one imap instance uses it with read-write lock. (This is just my interpretation of it so it may also be wrong)

[mikezzz]

So do we have to go to JDK 5 yet?

If only there was a way to do annotations in JDK1.4......Hold on :-).

- if conn 1 is not notiefied that the number of mails in the mailbox changed and he deletes the same mail on his first client (MSN 3)... the server will happily acknowledge it and delete MSN 3... what happens to be the former MSN 4... *boom*

An optimistic lock would prevent this. If the client performed an operation and the version held by connection 2 didn't match that on the folder, then we could force the event at that point. I would need to read the IMAP spec to be certain though.

it seems like it is missing something but I can't put my finger on it.

I know what you mean. I'm not 100% happy about having aspects that look at the data of the objects they are attached to, but I think in order to get the roles for the current object it will be necessary.

Would Hibernate filters be applicable here?

[acoliver]

Filters are good for not getting back folders you don't have access to (that may be yet another permission). .

I think I know what I don't like. I think that the interface is the issue. http://docs.jboss.org/ejb3/tutorial/security/src/org/jboss/tutorial/security/bean/CalculatorBean.java

Then I think the security data should be decoupled from the object.

SecurityService.getObjectRoles(clazz, approleFromMetaData, id);

thus clazz is the class (Folder.class), approleFromMetaData is "read" in the above sample and id is the primary key of the object (we will use all surrogate keys). I think we can get the primary key via some form of introspection (it will be marked)...

So I guess we should go EJB3 and JDK5 for the next release (M4) is that your supposition?

While I finish the izPack thing can you help knock out the non-install remiaing M3 issues?

http://jira.jboss.com/jira/browse/JBMAIL-16
http://jira.jboss.com/jira/browse/JBMAIL-33
http://jira.jboss.com/jira/browse/JBMAIL-35
http://jira.jboss.com/jira/browse/JBMAIL-34

Once we get that and I get the install ready I'll branch.

-Andy

[mikezzz]

So I guess we should go EJB3 and JDK5 for the next release (M4) is that your supposition?

It would be nice to move the EJB3 & JDK5 (mmm, new stuff), but it not necessary (more fun though) as I am quite happy with JBoss Annotations for JDK 1.4 and Hibernate (Mailbox/Maillist uses this).

Will look at the JIRA tasks.

Mike.

[acoliver]

okay good... I don't want to do JDK5 until M5 if possible.