9 Replies Latest reply on Apr 3, 2006 4:01 PM by darren hartford

    jbpm identity component needs

    Tom Baeyens Master

      inside of jboss many components need identity stuff.

      this thread describes and discusses the jbpm requirements for the identity component.

      * it should store user - membership - role as described in http://docs.jboss.org/jbpm/v3/userguide/taskmanagement.html#identity.model.image. Note that this model is a bit more elaborate then the typical J2EE user-role model with an nm-association between users and roles.

      * the core classes should be POJO's with hibernate mappings.

      * it would be great if we could reuse some CRUD webpages for managing users, memberships and groups.

      * very simplistic loading capabilities from xml file for testing purposes.

      * a custom login module would be nice although a DatabaseLoginModule works just as well.


      My current idea was to take a look at the portal identity component and merge the jbpm identity component with it and offer it as a separate module and package.

        • 1. Re: jbpm identity component needs
          Tom Baeyens Master

          Currently the JAAS authentication is done with a DatabaseLoginModule. The query is done on the identity tables.

          It might be a good idea to write a custom LoginModule that fetches the User, Memberships and Groups (all Principals) from the DB with hibernate and associate them with the authenticated subject. That way, all the plain java permissions that are stored in the database will be associated with the subject.

          See http://docs.jboss.org/jbpm/v3/userguide/taskmanagement.html#identity.model.image for the datamodel.

          • 2. Re: jbpm identity component needs
            Anil Saldanha Master

            JBossSX layer defines contracts to do the following:
            a) Establish the identity of an user via authentication (currently we do thru JAAS).
            b) Take this identity and authorize it against the application specified set of roles.

            What you have basically defined is deeper implementation details of how you want things in jBPM.

            I think you guys will highly benefit from the work that has happened in the portal project(as you mention). Julien has created a identity module. Portal does use custom login modules for authentication and for authorization, uses JACC (with permissions). I guess you will have to do an extension of what is happening in the portal space.

            • 3. Re: jbpm identity component needs
              Viet Master

              The identity model matches more or less the one we have in JBoss Portal.

              I think you are making a mistake in your model : you are mixing up 2 concerns : identity and security.

              The "entity" entity in your model should not be explicitely attached to "permission". Meaning that identity and security are 2 distinct concerns that you need to address differently.

              It maybe the case in your implementation that you have a database identity model implementation that would also modelize permissions though.

              • 4. Re: jbpm identity component needs
                Tom Baeyens Master

                 

                "julien@jboss.com" wrote:
                The "entity" entity in your model should not be explicitely attached to "permission". Meaning that identity and security are 2 distinct concerns that you need to address differently.


                disclaimer: as far as security is concerned, there is no agenda that i want to push cause i don't have much requirements there.

                practically: i'll definitely have a look at portal identity and see if i can integrate my extra requirements (if any) in that component.

                so what follows is just for my understanding.

                i don't see yet how the idea that i coined would mix identity and security in ways that are undesirable.

                In the coined proposal, the identity component stores users, roles, and other organisational information, but also authorization information in the form of plain java permissions.

                The idea was to create a data structure that maps easily onto the plain JAAS security.

                A login module associates a set of identities (read Principals) with the authenticated subject. The permissions associated to the principals determine the authorization.

                So the idea was that the 3 types of entities would match perfectly on the concept of identity (read Principal):

                * A user identity: The user itself is a typical identity, right ?

                * A membership can be e.g. a position in a company. E.g. the group represents an organisational unit such as your team and you fullfill the function of manager for that team. So also the function is seen as an identity and modeled as a membership for that group and optionally given some special privileges.

                * The fact that you are a member of a certain group can also be seen as an identity, right ?

                Ah... maybe you are referring to the fact that in this model the identities are fairly fixed... That is true with one remark. You can always create new group-types or membership-types that are some new kind of identity.

                So the given datamodel would imply a very simple implementation of a LoginModule:

                For a given user, fetch the User-object, and collect all the memberships and groups for that user. Those are all Principals and can be associated to the Subject. The permissions in the datamodel are now automatically used by the AccessController.

                So the the given identity model could also accomodate the JACC permissions. To give someone role based access to a certain webapplication, you could create a group that represents the role for that perticular application. Then you can associate the WebRoleRefPermission to that group.

                So afaict, this would be generic way to manage permissions for your users.

                Am i missing something ?

                • 5. Re: jbpm identity component needs
                  Viet Master

                  I am not talking about user/group/membership, what you are proposing looks sufficient to me and the use cases we have in portal so far, although that if we propose a richer model than portal (as this one) then we will leverage it.

                  Beside the fact that accessing the identity of someone and making a security decision is not the same thing (although it is related), we cannot just assume that a set of permissions is attached to one identity. For me this is an implementation detail.

                  For instance it should be possible to store user identity in one system (database for instance) and store permissions in another system (ldap for instance).

                  Also we want to be able to delegate authorization to thirdparty system in order to provide integration.

                  • 6. Re: jbpm identity component needs
                    Tom Baeyens Master

                    Julien,

                    i watched the JBP security presentation.

                    Why do you care about JACC for Portal ? JACC requires that a) app servers update the the JACC policy implementation with the JACC configuration API when deployments are done. and b) J2EE related security checks are done based on the jacc permissions.

                    So i don't see why you are trying to keep the JACC policy implementation up to date on the non-JACC portal secured policy information.

                    If Portal users plug in their own policy provider, they must manage the portal permissions in the policy provider's database, no ?

                    If i understand the presentation correctly, you try to keep the portal policy information in sync with the policy provider.

                    Afaict, we need an identity component with a matching login module and policy so we can ship with our own identity component that combines security and preferences out of the box. After that security remains pluggable because the login module and policy provider are configurable.

                    Then jBPM and portal just verify their own permissions with one of:

                    AccessControlContext.checkPermission
                    AccessController.checkPermission
                    SecurityManager.checkPermission
                    Policy.implies
                    Policy.getPermissions
                    Policy.getPermissions

                    Is this what you do in JBoss Portal ? Am i still missing something... probably :-)

                    • 7. Re: jbpm identity component needs
                      Scott Stark Master

                      JACC has no manifest APIs for permission checks. The APIs you are suggesting are what a security interceptor uses to validate access. JACC is simply the portable mechanism for integrating a deployment with the policy provider.

                      • 8. Re: jbpm identity component needs
                        Enrique Ruiz Newbie

                        Hi all,

                        Acegi Security System is an open source project that provides authentication and authorisation services for enterprise applications: http://acegisecurity.org/

                        Acegi Security can be used without Spring: http://acegisecurity.org/standalone.html

                        I hope it can be useful.

                        • 9. Re: jbpm identity component needs
                          darren hartford Expert

                          my two cents as a possible jbpm user -

                          Julien is correct from the standpoint of 'identiy' (aka authentication) and 'security' (aka authorization) and is a business problem that most enterprises come across. For example, in a scenario that I'm trying to accomplish we have all authentication coming from a single source, in this case ActiveDirectory (this was an enterprise decision beyond the scope of the application developer).

                          However, within an enterprise there may be many applications with different security models and policies that, more than likely, will NOT be maintained in the identity source (in this use-case, ActiveDirectory) and instead the Principal/authenticated identity will be used within the JAAS configuration to cross-reference authorizations. I.e., the JAAS config that has multiple modules, one with an identity/authentication module that is required, and one-N authorization modules for that policy.

                          The authorization module could be an application-managed database (aka databaseloginmodule for use only for authorization), LDAP, or whatever the application developer may be comfortable with while keeping enterprise-level identity (and SSO-like username/passwords managed by someone other than the application developer).

                          my two cents -- I would like to see integration for username/passwords for authentication, but then be able to manage authorizations (roles) for individual workflows.