remove domain concept in 1.1.0 ?

  • Charles Lescot

    Charles Lescot - 2007-02-19

    Hi team,
    i would like to have your opinion on removing the domain concept in jGuard.

    advantages of remove it:
    - deals with domain permissions and roles can be complex; remove domain reduces complexity
    - domains have been created to enhance permission management, but maybe a better way is to define some coarse grained permissions which implies multiple resources (urls) with the help of the star operator => it implies a good naming convention
    - domains (a pack of permissions) and roles (a pack of permissions too) are very closed...
    difference between role and domain is hard to find....
    -rbac standard does not implies domains

    disadvantages of remove it:
    - people uses since jguard inception domains
    - if people hasn't got a good naming convention, they have to do refactoring on their application due to jguard

    what is your feedback on it?



    • DocZorg

      DocZorg - 2007-11-24

      Hi Charles,

      I think that the domains are a very good thing, they allow a much better authorization management.

      When you talk about roles, you're talking about principals I guess?

      In my case, the domains are very useful, I work for a quite big company, and the definition of the permissions without the domains would be much more tiedious. I see domains like packs of permissions, and roles, packs of domains to which  we can add some individual permissions.

      Of course, the idea of using some wildcards for permissions is a good idea too, but I don't think it replaces the domains, but could be complementary ;o)

      I can give you more feedback once implemented.


    • André Pestana

      André Pestana - 2007-11-24

      Is possible to keep domain concept and create new ways of attributing permissions to principals?


      • Charles Lescot

        Charles Lescot - 2007-11-26

        Hi Neil and André,
        about keep domain and create a new way of attributing permissions to principals (i.e keep the two solutions):
        i think it is not possible easily, because domain is present in AuthorizationManager which is the key interface on the authorization side....
        it can be a nightmare to maintain these 2 ways.

        i think whether we should keep domain, or we should delete them.

        about neil post:
        "I see domains like packs of permissions, and roles, packs of domains to which
        we can add some individual permissions."
        => yes, you're right, that's the way it works.

        "In my case, the domains are very useful, I work for a quite big company, and
        the definition of the permissions without the domains would be much more tedious."
        =>i'm interested in your feedback.
        let me explain why i think domain concept should be removed :
        - domain idea is a duplicate of Role/Principal , i.e a bag of permissions
        - domain raise the complexity of the authorization management. its first goal was to enahnce role design and flexibility.
        but the major drawback is a too large flexibility! if you can create role with some part of permissions and/or overall domains,
        the easiest reflex is to create dozen of new roles when the ones previously created don't fit exactly to your needs.
        the result is one year later hundred of roles owned by one user (for each role)which are by definition  very specific to them.
        - another drawback about domain the the lack of visibility: what is the difference between a domain and a role? why a role owns an overall domain
        and some alone permissions?

        these few arguments try to excerpt that Role Based Access Control (i.e RBAC on which jGuard is mainly based) is a major step forward security management, but
        its main risk is the complexity.
        i've encountered a big company which is using a german  ERP in three letters (suspense). this ERP has evolved to manage its security on Role Based Access Control.
        but when i've seen how many roles have been created, and how many users own the same role, i was disappointed:
        hundred of roles was created , and only few roles were reused.
        one reason was that between roles and permissions, there was an intermediary level (like domain), which over-complexify the visibility (if you don't knwo which role to keep or reuse, you can grab this permission , and this domain and so on...).
        another reason was the absence of contextual-permission (i.e instance-based level permission).

        so, if you remove the domain concept, you simplify jGuard use, and restrain the facility to create hundred of roles.
        this option is not to hardening the jGuard use, but to highlight the fact that a permission is the right to execute some actions on one or more resources;
        and a role is a responsability in the webapp owned by one or more users which implies the use of one or more permissions.
        in the last sentence, i think you've understood that 'more' is a better than 'one' for a better flexibility/scalability/visibility.

        so, remove domain implies a better design choice when you create permissions( with a good naming convention) and roles, but permit to "survive the test of time" more easily (ok, this ads is comes from an old Sun tech days ;-) ).

        what is your feedback about my arguments?




Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks