1 2 Previous Next 15 Replies Latest reply on Jan 27, 2005 1:48 AM by acoliver

    JaasUserRepository

      A new JAAS UserRepository implementation is available. Currently it authenticates a user against a security domain, no checking for roles are done yet.

      To configure, edit the jboss-service.xml file. Comment the StaticUserRepository mbean, and uncomment the JaasUserRepository xmbean. Set the security domain to be used (can be changed later using jmx console).

      Create the security configuration in conf/login-config.xml. To quickly test the implementation, set the security domain to jbossmq, default users are guest/guest and john/needle among others.

      Testing results and comments welcome!

      Dawie Malan

        • 1. Re: JaasUserRepository
          pilhuhn

          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

            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

              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

                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

                  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

                    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

                      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

                        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

                          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

                            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

                              uhh...no because then ALL users would have access to *all* mailboxes. Unless I'm missing something..

                              • 12. Re: JaasUserRepository

                                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

                                   

                                  "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

                                    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.

                                    1 2 Previous Next