1 Reply Latest reply on Jun 2, 2011 10:05 PM by jasonah66

    Security Group Design

    jasonah66

      I am trying to determine what constitutes a groups in say LDAP vs what should be stored as domain data in an enterprise database.  Here are the particulars.  Suppose I am working with an application which has external users from multiple companies.  I want users in the same company to share access to certain tools on our side of the firewall and I want a custom look and feel for each company that the users from that company would see. Obviously I need to be able to determine which company a user came from as well as what the user's role is (sales, admin, VP, etc.).  In all cases that are known so far, pages will be created from standard templates.  Hierarchical URL security could be used to determine page acces for a specific role.  What I am trying to understand is whether the company that the user is a member of is domain data or is that an LDAP group?  In other words, what would be the guidelines in cases like this in general to determine what is appropriate for an LDAP group and what should be in an enterprise database?  Should the application discover the users' origins from LDAP or from a cross reference in the enterprise DB between the users' login IDs and their employer?

        • 1. Re: Security Group Design
          jasonah66

          No answer but if anyone else has similar questions here is what ended up happening in our casae.

           

          LDAP roles did in fact enter the relational DB.  I was not happy about that but it was neccessary for mapping to determine application accessibility for that prticular user.  Problem here is that the 'security role' as we refer to it in our dfomain model turned into a domain object.  Will likey end up being a value object.  This is partly due to some appearent Hibernate limitaions with multiple joins (I am still waiting for an answer on that).  Moslty though, security role becomes is an variable for determining needs of the rest of the domain.