1 2 Previous Next 15 Replies Latest reply on Feb 13, 2006 10:48 AM by soshah

    Drools Security

    anil.saldhana

      There has been a private thread going on between Michael Neale and me over the usage of an appropriate authorization framework in Drools. I want to invite Michael to use this design thread to chalk out the details.

      1) JBossSX is the security implementation in JBoss for the whole of the JEMS stack. It also includes a JACC layer.
      2) An UI for defining roles can be part of your application.
      3) You can do an lazy load of permissions, a role will have at the last minute. As long as you populate all the known permission types for your application in the PolicyConfiguration, just for the dispatch to the lazy permission collection.

      Michael Neale wrote:
      
      > Yeah that thread kind of touches on what I want to do (but perhaps is dealing with a larger quantity of data, but more or less the same).
      >
      > So can I clarify a few things about JACC and JBossSX? Its all very confusing to me.
      >
      > * Is JbossSX an implementation of JACC (and more?)
      > * If I use JACC/JBossSX are the roles defined "outside" my application? Is there an API/UI to assign users to these roles?
      > * Is there an API/UI for assigning application specific permissions (to the above roles) ?
      > * Is there a database structure that stores these permission assignments? (does JBossSX provide this?)
      > * To confirm, the enforcement of the permission/permissioncollection is done by my application in some kind of interceptor layer yes?
      >
      > I am just trying to work out what is the resposibility of my app, versus the framework.
      >
      > Also, I have some constraints that my repository may be used in any container (and not even in a JEE container), not just JBoss AS.
      >
      > Thanks for your feedback.
      >
      > PS I have been talking with Sohil about what he is doing with ACLs in the portal, so perhaps he is already solving this? He was looking at what I did regarding persistence, and was doing to adapt it to the framework (which I would then retrofit into my app).
      >
      > Michael.
      >
      > From: Anil Saldhana
      > To: Michael Neale
      >
      > Hi Michael,
      > from what I understand, you should be able to use JACC. You can
      > always define the permissions a particular role will have and then you
      > can check the permissions from your application against the ones in the
      > PolicyConfiguration.
      >
      > There is a way to do lazy permission collection checks also that allows
      > a security check to be made lazily (eg: read the latest perms from the
      > DB). So maybe in the lazy perm check, you can create the perm group and
      > check against that.
      >
      > See this thread:
      > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73586
      >
      > Regards,
      > Anil
      


      Hi Anil.
      >
      > Best is to look at the classes in:
      >
      > http://anonsvn.labs.jboss.com/trunk/labs/jbossrules/drools-repository/src/main/java/org/drools/repository/security/
      >
      > Basically any object in the repository database that implements
      > ACLResource *can* optionally have permissions set to a group of users
      > (the groups, which I really shoudl rename to be roles) are application
      > specific, and store in the apps database. This is row level security.
      >
      > The user identity is passed in to the app from the container outside
      > (i guess the roles could to??)
      >
      > From what I have read about JACC and xacml is that policies can be
      > fine grained, but it doesn't quite seem that fine grained. For
      > instance, from the OASIS website,
      >
      >
      > /Scope/
      >
      > XACML is expected to address fine grained control of authorized
      > activities, the effect of characteristics of the access requestor, the
      > protocol over which the request is made, authorization based on
      > classes of activities, and content introspection (i.e. authorization
      > based on both the requestor and potentially attribute values within
      > the target where the values of the attributes may not be known to the
      > policy writer). XACML is also expected to suggest a policy
      > authorization model to guide implementers of the authorization mechanism.
      >
      > The interesting part to me is "content introspection" where
      > authorization is based on attribute values. Now if it is "rule" based
      > stuff, say "you can see assets that are marked as 'HR' records, but
      > not 'FINANCE' etc" I can see that working, for sure. But then that is
      > pushing the authorisation basically on the content itself. Maybe I am
      > missing the point, but I thought really fine grained meant you
      > specified to the ACL exactly what resources are allowed to be touched
      > and how ...
      >
      >
      >
      > Ideas? Thoughts? Am I going down the wrong path? Should I move to
      > using policies that set rules of access rather then an ACL that
      > specifies individual records? (possibly.. thats a thought...)
      >
      >
      >
      > Michael.
      >
      >
      >
      > *From:* Anil Saldhana
      > *Sent:* Wed 1/02/2006 7:58 AM
      > *To:* Michael Neale
      > *Subject:* Re: ACL
      >
      > Hi Michael,
      > do you have some examples of your data related security that you talk
      > about?
      >
      > If I see some examples, then I can opine whether JBossSX will fit in.
      >
      > Regards,
      > Anil
      >
      > Michael Neale wrote:
      >
      > > Hi Anil. Our specific needs are really just for "data partitioning"
      > > type of security. I am not sure how JBossSX fits into that. From what
      > > I have seen of all the frameworks, they all fall short of providing a
      > > general solution to instance security (which is probably very hard to
      > > make general anyway, every app is slightly different in its data of
      > > course).
      > >
      > > Does this sort of instance/data security fit within the bounds of
      > > jbossSX from what you know? I can see that all the other stuff is
      > > still relevant, but the main problem we are trying to solve is
      > > instance security.
      > >
      > > MIchael.
      > >
      > > *From:* Anil Saldhana
      > > *Subject:* Re: ACL
      > >
      > > It basically depends on the location of your policy xml files as well as
      > > to what complexity is your "Policy Combining" Algorithms.
      > >
      > > My only request to all the project leads in search of a security
      > > solution, is to reuse the JBossSX layer as much as possible or suggest
      > > updates to it. Please run it with Scott, before embarking on a mission
      > > of your own. ;)
      > >
      > > If every project does its security in its own custom manner, with its
      > > own dependencies, then JEMS integration is ???
      


        • 1. Re: Drools Security
          michaelneale

          * Permissions will also be changing at runtime.
          * We need to provide an "administrative" interface for end users to set fine grained permissions.
          * We also need to be able to query out to see who can see what assets.

          • 2. Re: Drools Security
            michaelneale

            And ideally this needs to work container agnostic.

            • 3. Re: Drools Security
              soshah

              The way I understand JACC, its a security contract between the "container" resources and your application users. However, the granularity depends on what application layer you are talking about.

              Like in the case of portal JACC provides granularity to the level of protecting portal resources such as page, window, etc. With EJB you are maybe looking at protecting EJB Methods I guess.


              What Micheal is looking for is an application level security framework that has the concept of protecting high level business concepts, such as the resource that needs to be protected is "the user's ability to edit a particular drools rule in the database". So in this case the best solution would be a layer that understands business concepts and something that is extensible enough to introduce more business level concepts that need protection.


              Seems like JACC and an application level security framework complement each other rather than compete. They both solve a different set of problems and you its upto the application's security requirements as to which one should be leveraged.

              Anil, if you remember this is the same conversation which I had with you about portal's JACC layer's granularity vs the security granularity we need for the CMS.


              • 4. Re: Drools Security
                soshah

                Here are some of the concepts for a generic application-level security framework.

                1) Role ? Entity that you can associate your ACL permissions with. System users are then assigned to these roles to decide who has permission to do what on the system


                2) Module ? This is a way to divide/organize your system into modules of functions/activities. So for example: JBoss.com has User Module (for doing user management activities like login,logout, registration etc)

                And a CMS Module for doing activities like (access this resource from the CMS, Edit this resource in the CMS etc)



                3) Function ? This represents an application function/activity that needs to be protected. These are associated with a module. So a module is a collection of functions



                4) Resource ? This is the actual system level entity such as Java class method, a UI fragment on an HTML page, etc. (The idea is to perform a particular function end-to-end in a system, you need to access certain system level resources to make that happen). So resources are then associated with the above mentioned functions. You can also integrate custom resources in the context of the business concept that needs to be protected.



                5) Permission ? This is the actual permission granted to access a particular function in the system. The Engine maps from system resource being accessed to function that needs protection at runtime. Plus, this set of permissions are dynamic in the system



                6) Enforcer - An Enforcer is the object that actually performs the ACL logic and ?whether access should be granted or not?. The framework comes bundled with a DefaultEnforcer which should take care of 90% of ACL cases for an application. Applications can plug-in their own Enforcer that can perform this logic based on the runtime values, extra-parameter values etc. Basically all the information that the object will need to make a decision whether access should be granted or not. Having the Enforcer perform the access control logic keeps any ACL checking code to be hard coded within the business logic of the application or library. This leads to better flexibility from a security perspective of the system. You can easily swap out ACL security infrastructure without having to modify any application/library code



                • 5. Re: Drools Security
                  soshah

                   

                  "anil.saldhana@jboss.com" wrote:

                  > /Scope/
                  >
                  > XACML is expected to address fine grained control of authorized
                  > activities, the effect of characteristics of the access requestor, the
                  > protocol over which the request is made, authorization based on
                  > classes of activities, and content introspection (i.e. authorization
                  > based on both the requestor and potentially attribute values within
                  > the target where the values of the attributes may not be known to the
                  > policy writer). XACML is also expected to suggest a policy
                  > authorization model to guide implementers of the authorization mechanism.
                  >
                  > The interesting part to me is "content introspection" where
                  > authorization is based on attribute values. Now if it is "rule" based
                  > stuff, say "you can see assets that are marked as 'HR' records, but
                  > not 'FINANCE' etc" I can see that working, for sure. But then that is
                  > pushing the authorisation basically on the content itself. Maybe I am
                  > missing the point, but I thought really fine grained meant you
                  > specified to the ACL exactly what resources are allowed to be touched
                  > and how ...


                  This part of XACML seems very interesting. I haven't had the chance to look at the spec yet, but from this it seems it takes the approach of providing a standard based ACL layer for protecting application level activities.

                  • 6. Re: Drools Security
                    soshah

                     

                    "sohil.shah@jboss.com" wrote:

                    Like in the case of portal JACC provides granularity to the level of protecting portal resources such as page, window, etc. With EJB you are maybe looking at protecting EJB Methods I guess.


                    What Micheal is looking for is an application level security framework that has the concept of protecting high level business concepts, such as the resource that needs to be protected is "the user's ability to edit a particular drools rule in the database". So in this case the best solution would be a layer that understands business concepts and something that is extensible enough to introduce more business level concepts that need protection.


                    Just to clarify this point, JACC takes the approach of associating permissions with system level resources like (EJB Methods, Portal Page, Portal Window) etc. It has no knowledge of the "business function" that is associated with a collection of these resources that are strung together to perform this one single activity.

                    The application security layer flips this approach and associates permissions with "business function/activity" and does not care what the system level resources are to perform this activity. Ofcourse, there is a mapper that maps the business activity to its collection of "resources" so that the ACL Engine can automatically say "ok, this resource is being accessed, so it is this activity that is being performed". Ofcourse, the collection of resources associated with an activity do not necessarily have to be system level resources. This can be extended to include resources in the application's context.



                    • 7. Re: Drools Security
                      michaelneale

                      The "Roles" that are defined will not really line up with any groups that would exist outside of the application. Not at all.

                      These roles would be wholly defined by the business users of the application.

                      In my experience, in large organisations, user groups and group member ship is very tightly controlled, and not particularly suited for fine grained access control. Its great for locking down apps/urls etc (who can access what) but it doesn't seem to be used to control authorisation inside an app much (other then perhaps allowing or denying a person rights to see the internal "admin"/management features of the application itself).

                      I am taking URL/method type security as a given, as any container can do this, the challenge is the ACL for fine grained resources (which may be based on content patterns, or particular items of content).

                      Role membership also must be controlled from a management layer which is application specific (so the department that owns the rule system, controls access lists - NOT the IT department).

                      I gather JACC can do a lot of this, but I am not so clear about the Role and ACL components.

                      Does any of that make sense?

                      • 8. Re: Drools Security
                        soshah

                         

                        "michael.neale@jboss.com" wrote:

                        I am taking URL/method type security as a given, as any container can do this, the challenge is the ACL for fine grained resources (which may be based on content patterns, or particular items of content).

                        I gather JACC can do a lot of this, but I am not so clear about the Role and ACL components.

                        AFAIK, yes.
                        JAAS provides standardized authentication so that the system knows who you are. This works perfectly.

                        After authentication comes authorization which is where JACC comes in. The primary issue is the granularity offered with JACC.
                        It may be enough for most applications, while that may not be enough for other applications.

                        The primary issue seems to be permission association with (container components without any knowledge of the actual business activity being performed) vs permission association with (a high level business activity regardless of what components are used to actually implement the activity end-to-end).

                        As far as Role Management goes, that should primarily be an application level feature whether JACC is used for authorization or something else. As long as it can feed the authorization engine with information it needs to calculate your access rights, it should work

                        One more easily over-looked issue with ACL control is embedding ACL related logic along side the actual business logic. This leads to very inflexible application with very tight coupling with whatever security framework you decide to choose in the beginning. ACL logic IMO should be treated as a cross-cutting concern in the application.

                        • 9. Re: Drools Security
                          anil.saldhana

                          Sorry I have been travelling this week.

                          Regarding Roles and ACL, here is my take.

                          If you do authentication via JAAS, you can set up an authenticated subject. The subject needs to be populated with a role somehow, for the identity that is logging in. So the association of a role to the authenticating identity is external.

                          Now that you have the role, JACC can do lazy dispatch to do a permissions check for the role. At the location where you do lazy perm check, you can obtain a fresh set of current permissions from anywhere (lets say a DB) for checking.

                          To answer the question of users defining custom permissions, it should be fine thru a custom UI.

                          Michael, what is your roadmap for Drools security?

                          • 10. Re: Drools Security
                            starksm64

                            JACC is just a mechansim for the container to map the ejb-jar/web declarative permission checks to a pluggable java.security.Policy style of authorization layer. In terms of this discussion its just a Policy based authorization model and as such the granularity and dynamic characte of the authorization policies is up the the implementation. Any permission outside of the ejb/web security model is an extension to JACC. This is what is relevant here as we have been looking at JACC as just the first step in generalization of the legacy Java EE security model.

                            • 11. Re: Drools Security
                              michaelneale

                              There is no specific roadmap at present. Future directions will be based on users needs (at the moment it is pretty vague).

                              This is just for an "optional" feature for people who wish to use the rule repository. You will be able to use JBoss Rules just fine without even touching the repository.

                              And you can use the repository without security - it is also optional. So it is a feature that just has to be there but will most likely (initially) rarely be used.

                              What I have now is based on an Interceptor enforcing the access, and a simple DB structure for storing the permission to role assignments. The roles have nothing to do with container type roles at present - I am not sure if this is a good thing or not.


                              • 12. Re: Drools Security
                                michaelneale

                                Sohil I am sure there is quite a lot both the rule repository and the portal have in common in terms of fine grained controls.

                                However, we will need to be able to access the ACL data programmatically in different ways (for instance, I will want to use mine in querying data).

                                The commonality ideally would be an implementation API, a database schema and (possibly) an interceptor, and a perhaps a UI (not sure about the last to being able to be generic enough).

                                • 13. Re: Drools Security
                                  anil.saldhana

                                  Michael, there is a clear possibility of having an api driving the authorization layer. How you map your needs to the api is what needs to be chalked out.

                                  Basically, we will need all the usecases from every project so that a common api can be derived. We cannot force you to use jacc in your project but certainly an api with a pluggable implementation is a positive direction.

                                  • 14. Re: Drools Security
                                    soshah

                                     

                                    "michael.neale@jboss.com" wrote:

                                    However, we will need to be able to access the ACL data programmatically in different ways (for instance, I will want to use mine in querying data).

                                    Agreed. I think is an essential feature of the generic framework. I am sure other applications have this need as well.

                                    "michael.neale@jboss.com" wrote:

                                    The commonality ideally would be an implementation API, a database schema and (possibly) an interceptor, and a perhaps a UI (not sure about the last to being able to be generic enough).

                                    Agreed. the generic framework should provide default implementations for the above components. The specific applications can then override or plug-in custom implementations based on their needs.

                                    1 2 Previous Next