-
1. Re: JaasUserRepository
pilhuhn Jan 14, 2005 7:16 AM (in response to djmalan)Sounds cool.
I assume it is time now to provide a generic user administration feature, as JBMail users probably don't want to add users directly via sql. -
2. Re: JaasUserRepository
djmalan Jan 14, 2005 8:20 AM (in response to djmalan)Yes, I'm working on it. The idea is to implement a "general" LoginModule that will provide hibernate users/groups/roles persistence for users that don't have an existing implementation.
Priority right now however is the hibernate mailbox implementation, I will post some more about that during the course of the weekend. -
3. Re: JaasUserRepository
acoliver Jan 14, 2005 11:35 PM (in response to djmalan)I may be cracked (so please argue) but here is my
basic idea:
JAAS
Subject
Principal -- Credential
Roles
Mailbox
name
roles []
folders []
Folder
name
mailbox-name
roles[]
If you have any of the roles associated with the mailbox, you can access the mailbox. Mailboxes have folders (for pop you only access "INBOX"). Folders are also associated with roles. If you have any roles associated with a folder you can access it.
We need to read more IMAP to find out whether you should see folders that you can't access or whether that should just be an option or what.
We can store other information in the Subject such as "DefaultMailbox" = "INBOX" when using a JBMail specific login module, but the goal is to allow users to be able to use the generic JBoss login modules as well. (Maybe we need to extend them to allow them to get other information, but the goal is what is important).
Other thoughts? Questions? -
4. Re: JaasUserRepository
pilhuhn Jan 15, 2005 2:28 PM (in response to djmalan)Can you elaborate a little more on what you expect as roles?
Suppose the case:
User B has read access to User A's mailbox while A is on vaccation (read, not write/change).
User C has read/write access to User A's calendar folder, but not to the mailbox.
Hmm.
RFC 2683 has advices on imap implemenation considerations. A link is on the wiki. -
5. Re: JaasUserRepository
acoliver Jan 16, 2005 4:19 AM (in response to djmalan)Roles are strings. I mean roles as can be assigned by JBoss login modules. The reason that I would use said login modules to assing the roles is that the login modules pre-exist. Furthermore for mail-based/mail-driven applications they fit in nicely with the rest of JBoss.
Right now I'm thinking of mailboxes only (not Calendar). Writing is to me Othogonoal to mailbox/folder permissions (though I could be wrong). Thus the permissions that allow me to send "mail from" an identity are not necessarily connected to mailbox permissions. At JBoss there is a person called atlanta reception. I'm sure this person has a name but I will always know her as atlanata reception because that is what her email identifies her as. Now it is quite possible that one day Atlanta Reception will spawn Atlanta Receptionlets (possibly from some form of mitosis) and they will all read the same mail box/folder. Moreover there is the little used "public folders" feature of outlook/friends. etc. etc.
Yes I saw the links. I have read most of them but will leave the detail up to the implementor(s) with just gentle nudges :-) -
6. Re: JaasUserRepository
djmalan Jan 16, 2005 5:00 AM (in response to djmalan)There is also the issue of tracking individual message flags per user. For instance, if a mailbox has two users, each user must be able to flag a message as read without affecting the other user's flags.
The current (not yet commited) mailbox implementation provides a list of subscribed users per mailbox. Each user has a seperate pseudo-mailbox. Since mailboxes do not store actual messages, but only a reference to a message in the message store, the overhead is not significant.
JAAS provides a domain-wide role mapping, with no way to specify what object the role applies to. What we need is a role per folder. One way to get around this problem is to impose a naming convention, something like <object name>.<role name>, but this may be difficult to configure if the installation uses an external system to manage users and roles.
Perhaps a solution would be to develop a custom login module that can manage the roles for jbmail, using another (optional) login module to provide authentication, or else a completely seperate access rights module, using JAAS for authentication and system-level security. -
7. Re: JaasUserRepository
acoliver Jan 18, 2005 12:45 AM (in response to djmalan)General principal I'm trying to accomplish:
1. KISS
2. IT should be possible to use login modules that come with JBoss with JBMail.
It is acceptable if #2 dumbs down security and we offer login modules that do better things. It is also possible to add more sophistication (provided it can be turned off) to existing JBoss login modules. I'm sure someone else needs it too. If Scott Stark is trolling maybe he can offer some suggestions on security as well. -
8. Re: JaasUserRepository
pilhuhn Jan 23, 2005 3:15 PM (in response to djmalan)As one is able to stack login-modules, the existing ones can be used to autenticate users and have JBMail specific ones that do fancy things.
I am with Dawie, that we need permissions per object. -
9. Re: JaasUserRepository
acoliver Jan 23, 2005 7:10 PM (in response to djmalan)Right but that can also be accomplished potentially with RoleGroups. I'm not arguing against the feature, just that the default use case should be simple: Every user has his own mailbox with like one or two folders and only he can read it. That's the "default" case and should require next to no setup and should just work with normal login modules. The architectural ideal here is that we have pluggable policies/mailboxes and security. What we need is a way to implement security as a cross-cutting concern and support at least the simplistic as well as the more flexible model of security.
-
10. Re: JaasUserRepository
djmalan Jan 24, 2005 4:11 AM (in response to djmalan)I think what Andrew wants to achieve is a very simple installation where the user does not need to change anything on an existing JBoss installation to get JBMail running.
My suggestion:
Basic mailbox configuration provides the following folders - INBOX, Sent, Draft and Trash. To access the mailbox the user will require a role jbmail-. The user will have full access to the mailbox i.e. read, write, delete, create folder, delete folder.
We may extend this to include specific roles e.g. jbmail--create-folder etc.
Postmaster access provides full access to the mailbox subsystem, and requires a role jbmail-postmaster. We may also extend this to restrict postmasters to domains, such as postmaster--add-user etc.
Any other attributes and flags associated with the mailbox will be handled by the mailbox system itself, including additional security attributes. In this way JAAS provides authentication and access control, and all mailbox-related details are managed by the mailbox implementation. -
11. Re: JaasUserRepository
acoliver Jan 24, 2005 10:56 AM (in response to djmalan)uhh...no because then ALL users would have access to *all* mailboxes. Unless I'm missing something..
-
12. Re: JaasUserRepository
djmalan Jan 24, 2005 12:17 PM (in response to djmalan)The forum s/w gets confused with << characters and dropped some of the previous post, I'll use curly braces instead:
jbmail-{username}-access
e.g. the role "jbmail-testuser-read" will grant read access to the testuser mailbox.
Rights could include read, write, delete, create-folder, delete-folder and full.
The jbmail- prefix would distinguish the roles from other possibly pre-existing roles in the JAAS repository. -
13. Re: JaasUserRepository
acoliver Jan 24, 2005 2:56 PM (in response to djmalan)"djmalan" wrote:
The jbmail- prefix would distinguish the roles from other possibly pre-existing roles in the JAAS repository.
We don't want to distinguish from other pre-existing roles. For the mail driven application case folks may use mailboxes or process mailboxes or something. They may use application roles throughout. We don't want to stop them from using their existing roles.
-andy -
14. Re: JaasUserRepository
djmalan Jan 24, 2005 4:04 PM (in response to djmalan)In that case the only solution I can see would be to make it all configurable, i.e. when you create a mailbox you have to configure the required roles for that mailbox.