mailboxes and authentication

[kabirkhan]

I am looking at the error reporting, and have noticed an issue with the EntityMailBox. Basically, whenever you try to get a specified mailbox via
MailBoxManager.getMailBox()
which is implemented by
EntityMailbox.getMailBox()
a new EntityFolder is created for the specified username, which is then used for loading up the messages. Valid mailboxes do not seem to be specified anywhere, and no password authentication for the mailboxes has been built in yet. Issues caused by this are:
-Messages for local delivery will always get delivered
-POP clients can access anything they like: if they specify a user who really does not "exist" (as mentioned they are not defined anywhere) they will be able to log in and the STAT command will return '+OK 0 0'. If they specify a user who "exists", they can send in whatever password they like and get the messages.

So it seems we need to do some authentication for mailboxes. The simplest way seems to link this up with the UserRepository somehow, so that it checks the userrepository while/before obtaining a mailbox folder. Have I missed out something? Is this perhaps what the MailServicesPolicyMBean is meant to handle?

Cheers,

Kab

[acoliver]

Yes I've thought of this and haven't yet quite worked my way though it. We need this for a few things including mail lists. What do you think should be done? Keep in mind that the user repository should be pluggable. Perhaps mail boxes are associated with multiple users etc??

[mikea-xoba]

i think as it stands now, org.jboss.mail.mailbox.Folder is an ok interface.

as far as authentication goes, wouldn't we eventually want to use something based on javax.security.auth.spi.LoginModule? and also use entity beans for user accounts and relate them by CMR (1-N) to our MessageBeans rather than use a 'folderName' CMP field? pretty simple to extend org.jboss.security.auth.spi.UsernamePasswordLoginModule if we want to do this.

may also be useful to have a mailing-list entity bean, in a many-to-many relationship with the user entity bean.

in this case, i'm guessing we'd want to have a common ServiceProxy interface which both StaticUserRepositoryMBean and (doesn't exist yet) something like 'EntityUserRepositoryMBean' make available, which also has methods having to do with mailing-list addresses? the implementation provided by EntityUserRepositoryMBean would invoke entity bean and finder methods, most likely through the LoginModule i just mentioned.

i believe that if a mailing list message goes out to 100 people, there will only be one or two header lines that differ among all those messages, so we may want to at least break our single MessageBean into two --- one containing a monolithic String 'headers' CMP field, and the other containing the 'body' CMP field; they'd be joined up in a bidirectional 1-N CMR (one body for many sets of headers). so then we could well-represent 100 duplicate message bodies as a single bean and save space/time etc.. this would be much less 'fine-grained' than my earlier proposal; but again, this could be implemented later with virtually no penalty since i think our interfaces are well designed and there are more pressing issues right now.

[a_sogor]

I think authentication and authorization should work with the existing security realms JBOSS already has.

The really exciting thing about a mailserver in JBOSS would be that you can add an other/mail based intarface to your applications. Think about the possiblity of writing hooks to handle custom work flows, invoke services based on the arrival of some messages.

The problem with having a separate security model for the mailserver and the rest of the services in the container is that now you have to integrate twice to like a corporate LDAP server(ActiveDiretory?).

I suggest separating user repository for custom(M1) attributes. Provision the M1 attributes to the M1 storage after succesfully authenticated via the realms. Provide a hook for the provisioning.

For example:
- new user to M1 logs in.
- user known the the JAAS realm authentication succeed.
- load user profile to M1. Find none.
- Invoke provisioning hook, provide userID.
- provisioning hook implementation does magic to retrive infomation from somewhere. Return M1 user profile.
- save profile.

[spiritualmechanic]

I'm just throwing this out here, nix it if it's stupid, just trying to think. I need to grab the latest head as I haven't looked at the code in a few weeks.

What could be done is tie folder to role.

This would allow multiple users to be tied to a role, or one user if all you want is one.

In this scenario, a role would behave as a group, which may present some problems. WebLogic Portal used to do something like this, which ended up being confusing, the way they implemented it for web apps.

How is a user (or an admin) going to want to manage security? Is a user going to want to look at a list of roles, or be able to add roles on the fly?

Steve

[spiritualmechanic]

Actually, now that I think of it, roles may not map very well from Exchange client type of usage.

I don't use Exchange client, so I'll do a little research.
Steve

[acoliver]

That actually made some sense to me even if it it will sicken some purists. "roles are supposed to be functional" though we may be forced to do something like ACLs (microsoft's preferred way to do everything). But boy oh boy do I hate ACLs. (As I think I probably ranted to you in person ;-) )

Still for simplicity it may be easier to have a hangnail off of JBoss SX rather than try and make roles fit... Ultimately at the JAAS level though, we have Subject->Principal and there is no necessity that these be roles per say. someone should definitely look into this. Think at least far enough in the future for IMAP but not much further as we can refactor later :-)

[spiritualmechanic]

Yeah I hate ACLs too. Even when they were in Weblogic server I hated them. I just was thinking "What would Java do?" and although roles should be functional, it's the idea that most easily maps to web.xml and the security/role parts of ejb-*.xml.

If we can, we should have as consistent an interface as possible (consistent with J2EE) without thrusting the MCSE's into the world of Java roles in XML.

Steve

[acoliver]

Yes, but remember that Entity is only one implementation. In the future we'll hopefully have a Hibernate one, etc. I don't want to now until there is more complete integration between JBoss and hibernate.

[starksm64]

What are the items that need to be secured, and what are the granularities? The Java model is either roles or permissions with the latter needing some acl spec, for example xacml which is something I'm planning on integrating anyway. One xacml starting point being:
http://sourceforge.net/projects/sunxacml.

[spiritualmechanic]

Got this from
http://www.microsoft.com/technet/prodtechnol/exchange/55/reskit/exapd.mspx


Setting Up a Delegate User on a Mailbox

You can assign another user to act as a delegate for a user's mailbox or Schedule+. A delegate can perform various activities depending on the permissions the mailbox owner grants to the delegate.
To grant a user Delegate permission for a mailbox

1.


Log on to the Microsoft Exchange Client as the mailbox owner.

2.


In the folder list, select the mailbox or a mailbox folder.

3.


On the File menu, click Properties, and then click the Permissions tab.

4.


To add a name to the Name/Role list, click Add.

5.


Under Type Name Or Select From List, type or select the name, click Add, and then click OK.

6.


In the Name/Role list, select the name of the user you want to grant permission to.

7.


Under Permissions, select a predefined role in the Roles box or select the individual permissions.

You must grant a minimum of Read Items (Reviewer role) permission to allow another user to open the mailbox.

8.


Click OK.


So it looks like not only will you have to manage roles, but permissions as well. Also, be able to add "Types" whatever that may map to.

Steve

[spiritualmechanic]

Looking into sunxacml.