7 Replies Latest reply on Mar 29, 2002 7:56 AM by cobraflow

    :-( Realm/Domain conf problem

    cobraflow

      Hi,
      I have :-

      auth.conf (Server)

      X {
      ...
      };

      Y {
      ...
      };

      other {
      ...
      };

      1) My EJB's use the 'other' domain.
      2) WebApp1 uses 'X' domain and EJB's
      3) WebApp2 uses 'Y' domain and EJB's

      ...The problem is that if I start a clean JBoss(2.4.3) (nothing in db/sessions, tmp/deploy, work), my WebApp's authenticate correctly but then the first EJB I call tries to authenticate against 'other' - failing. If I retry the App it all works! (The EJB's do not try to authenticate against 'other')

      My main questions are :-
      1) If there is already an authenticated Principal from the WebApp (which has the required roles for the EJB's!) should the EJB's ever try to authenticate the Principal against 'other'?
      2) Is there a way to pass a 'Domain' around with the principal?

      Kind regards

      Lewis

        • 1. Re: :-( Realm/Domain conf problem
          cobraflow

          ...new Info!

          1) I open a secure JSP and WebApp1 authenticates to domain 'X'.
          2) I create a reference to Stateful Session 1 (Principal is propagated)
          3) I call a method on Stateful Session 1 which in turn creates a reference to Stateful Session 2. It is this second EJB that is trying to authenticate against 'other'. I assumed that the principal should be propagated between EJB's!

          Am I doing something stupid? What should I look for?

          Kind regards

          Lewis

          • 2. Re: :-( Realm/Domain conf problem
            annegret

            Hi,

            What do You mean with "My EJBs use the 'other' domain" ?
            Did You specify the 'other' domain for the EJBs or do they run as a role known in the 'other' domain ?

            In jboss.xml You must specify a security-domain for the EJBs and all EJBs in that jar-file will always authenticate against that domain. So for my understanding if You need the same EJB one time authenticate against X and other time authenticate against Y You need to deploy it twice in different jars and specify the security-domain X for jar1 and Y for jar2. (If that's what You want to do !?)

            The principal itself will be propagated to other EJBs but the required roles for the bean access are checked by the EJB server using the specified domain

            Hope this helps

            Annegret

            • 3. Re: :-( Realm/Domain conf problem
              cobraflow

              Thanks for the reply!

              1) My EJB's authenticate against domain 'EJB' for example.
              2) My WebApps each authenticate their own domains.

              When a user hits a WebApp he is authenticated against the WebApps domain. The principal is populated with the username, credentials, roles etc. That principal is then used in communication with the EJB's (They do not need to 're-authenticate' against their own domain)

              What I am seeing is that the user is authenticated against the WebApp domain correctly, then an EJB method is called with the current principal (the correct roles for the EJB method exist inside the principal) and so the EJB authentication is NOT fired. (I assume that this is correct) Then, this is where my problem occurs, the EJB, in performing the method, creates a reference to another EJB. On hitting the second EJB method (the roles in the principal are correct for this method call as well) the second EJB authenticates. It is authenticating with a null principal! I assume the principal was lost for some reason forcing the second EJB to try authentication!?

              I hope this makes a little more sense!?

              Lewis

              • 4. Re: :-( Realm/Domain conf problem

                Hi,

                I think you'll need to supply more technical information before you'll get a solution. i.e. what has led you to the conculsions you give. And what web container are you using? Is it integrated or external? Have you tried the latest release versions? Does your system work OK if you use the same security domain for the web and EJB parts?

                What do you mean by "the second EJB authenticates"? And by roles being "inside the principals"? And "authentication is NOT fired"? All calls to secured EJBs will be authenticated.

                Luke.

                • 5. Re: :-( Realm/Domain conf problem
                  cobraflow

                  Luke,
                  I hope this lot helps!

                  This solution would be cool if it works. It allows applications to authenticate against seperate domains therefore allowing sharing of EJBs amongst different Web-Applications on the same server.

                  /*
                  The use of the 'EJB'='EJB' etc in the queries is purely for debugging so that when I dump the current query to the screen I see which one is called!

                  When a user logs in I see the D1 domain authenticating.
                  When the user gets to a point where the first method call on an EJB I also see D1 authenticating.
                  When the first EJB calls the second I see the EJB domain authenticating with a null principal. To avoid problems I have added EJB roles for 'Guest' as
                  the unauthenticated identity. This 'works'.

                  I only see EJB authenticating infrequently. If I am correct in my assumptions that the original Principal authenticated against Domain1 should be
                  propagated to the EJB's, then :-

                  1) Why should the EJB domain ever be authenticated against as the user is ALWAYS authenticated against Domain1?
                  2) Why is the first EJB ok but then the second level EJB not?
                  */

                  /*
                  This domain should never be used as ALL applications that use the EJB's are WEB-APPs with their own domains (I assume!!!!)
                  */
                  EJB {
                  com.cf.rt.server.security.DatabaseDomainServerLoginModule required
                  unauthenticatedIdentity="Guest@"
                  dsJndiName="java:/CobraFlowDS"
                  principalsQuery="select Credentials from WFPrincipal1 where 'EJB' = 'EJB' And Domain=? And Principal=?"
                  rolesQuery="select Role = Case Global When 'y' Then Role Else Role + '@' + Domain End, RoleGroup from WFRole1 where 'EJB' = 'EJB' And Domain=? And Principal=?";
                  };

                  /*
                  Domain1 is used by WEB-APP 1. When a user hits the first page in the app he is authenticated here. He uses 'user@domain' as his username. The login module splits
                  this into principal and domain for use in the two queries.

                  On return from the rolesQuery the user will(should!) have :-

                  1) WEB-APP roles - These roles allow access to the available pages
                  2) EJB roles - These are the roles required to access the available methods on the EJB(s)
                  */
                  Domain1 {
                  com.cf.rt.server.security.DatabaseDomainServerLoginModule required
                  dsJndiName="java:/CobraFlowDS"
                  principalsQuery="select Credentials from WFPrincipal1 where 'D1' = 'D1' And Domain=? And Principal=?"
                  rolesQuery="select Role = Case Global When 'y' Then Role Else Role + '@' + Domain End, RoleGroup from WFRole1 where 'D1' = 'D1' And Domain=? And Principal=?";
                  };

                  Domain2 {
                  com.cf.rt.server.security.DatabaseDomainServerLoginModule required
                  dsJndiName="java:/CobraFlowDS"
                  principalsQuery="select Credentials from WFPrincipal1 where 'D2' = 'D2' And Domain=? And Principal=?"
                  rolesQuery="select Role = Case Global When 'y' Then Role Else Role + '@' + Domain End, RoleGroup from WFRole1 where 'D2' = 'D2' And Domain=? And Principal=?";
                  };

                  • 6. Re: :-( Realm/Domain conf problem

                    > 1) Why should the EJB domain ever be authenticated against as the user is ALWAYS authenticated against Domain1?

                    This is correct. You are confusing "authentication" with "calls to your login module database code". *Every* call to an EJB should be authenticated against the configured security domain. If the web security is using the same domain, then the credentials will be cached so you won't see a call to the database.


                    > 2) Why is the first EJB ok but then the second level EJB not?

                    Not sure. How are you setting up the security domain configuration - are you doing it per bean, or what?

                    I don't really understand why you have things set up this way. It seems that you are duplicating security information in the database by including the domain in your query. Each user must have a separate entry for each domain, yet they must all be interchangeable otherwise you won't be able to propagate the credentials between security domains.

                    Luke.

                    • 7. Re: :-( Realm/Domain conf problem
                      cobraflow

                      Luke,

                      1)
                      >*Every* call to an EJB should be authenticated against
                      >the configured security domain.

                      ...I think this should be '*Every* call to an EJB should be authenticated against the current principal if it exists else the configured security domain.'

                      2) The security domain for the EJBs is set up using the 'default' of securing all EJB's against one domain. FYI the EJB's are also deployed in a single EJB jar.

                      3) When hosting applications for different 'groups' of people ie Departments or Companies, the data and applications need to be separated by 'domains'. Using this method I can enable users from different companies to use the same application/ejb's without mixing data. A 'domain' column is added to application tables to keep data separated. The alternative would be to create tables for each company. This route also allows, in the case of splitting by 'department', users to cross 'domain' boundaries for reporting etc.

                      Lewis

                      P.S. I am always open to a better solution ;-)