Configuration de la sécurité EJB sur Weblogic

Question

J'essaie de comprendre le fonctionnement de la sécurité EJB sur un serveur WebLogic.

J'ai un EJB avec la configuration suivante dans ejb-jar.xml

<session> 
    <ejb-name>BeanA</ejb-name> 
     .... 
     <security-identity>    
      <run-as> 
       <role-name>beanA_users</role-name> 
      </run-as> 
     </security-identity> 
</session> 

     <assembly-descriptor> 
      <security-role> 
       <role-name>beanA_users</role-name> 
      </security-role>  
      <container-transaction>  
       <method> 
        <ejb-name>BeanA</ejb-name> 
       <method-name>*</method-name> 
       </method> 
      </container-transaction> 
     </assembly-descriptor> 

et weblogic-ejb-jar.xml:

<security-role-assignment> 
    <role-name>beanA_users</role-name> 
    <principal-name>runas_a</principal-name> 
</security-role-assignment> 
<run-as-role-assignment> 
    <role-name>beanA_users</role-name> 
    <run-as-principal-name>runas_a</run-as-principal-name> 
</run-as-role-assignment> 

Je l'interprète comme ceci: Beana fonctionne comme beanA_users. "runas_a" est l'un des beanA_users. Par conséquent, BeanA s'exécute en tant qu'utilisateur runas_a. En outre, tous les utilisateurs qui sont dans le rôle beanA_users sont autorisés à appeler toutes les méthodes BeanA. En d'autres termes, Bean_A s'exécute sous runas_a, et seulement runas_a peut appeler ses méthodes. Est-ce correct?

Cependant, lorsque j'appelle cet EJB d'un autre EJB ayant la configuration ci-dessous, je peux passer à travers. Ne devrait pas Bean A configurer une permission pour le principal assigné au rôle BeanB_users dans le BeanB?

ejb-jar.xml:

<session>  
    <ejb-name>BeanB</ejb-name> 
      ... 
     <security-identity>    
      <run-as> 
       <role-name>beanB_users</role-name> 
      </run-as> 
     </security-identity> 
</session> 

weblogic-ejb-jar.xml:

<run-as-role-assignment> 
    <role-name>beanB_users</role-name> 
    <run-as-principal-name>runas_b</run-as-principal-name> 
</run-as-role-assignment> 

Edit:

Après avoir lu le schéma ejb-jar.xml il ressemble le Bean A dans cet exemple ne définit aucune autorisation dans l'élément <assembly-descriptor>. Il définit uniquement le rôle de sécurité. Je présume que c'est la raison pour laquelle n'importe quel EJB peut appeler ses méthodes. Mais pourquoi définit-il une attribution de rôle de sécurité dans ce cas? Par exemple, si BeanA avait ce qui suit dans l'élément, dans ce cas, bloquerait-il BeanB puisque la permission n'inclut pas le principal runas_b?

<method-permission> 
    <role-name>beanA_users</role-name> 
     <method> 
      <ejb-name>BeanA</ejb-n‌​ame> 
       <method-name>*</method-name> 
     </method‌​> 
</method-permission‌​> 

Answer 1

Vous avez la mauvaise extrémité de la clé ici.

Lorsque vous ajoutez:

<security-identity>    
     <run-as> 
      <role-name>beanA_users</role-name> 
     </run-as> 
    </security-identity> 

à une définition de haricot, cela indique WebLogic quel rôle devrait être appliqué à toutes les invocations sur le grain de café qu'elle se dynamise, plutôt que ce que l'utilisateur dynamise. Par exemple, cette identité de sécurité serait appliquée aux méthodes de temporisation EJB et à la méthode onMessage d'une MDB (et si je me souviens bien, certaines opérations d'entretien ménager).

L'extension WebLogic avec l'élément <run-as-role-assignment>...</run-as-role-assignment> ajoute un principal défini à ces appels de méthode afin que javax.ejb.EJBContext.getCallerPrincipal() renvoie autre chose que anonymous pendant l'un de ces appels de méthode.

Dans tous les autres cas, ces informations de sécurité sont normalement propagées à partir de l'identité de l'utilisateur connecté d'une application Web.

Généralement, un utilisateur sera authentifié via son application Web basée sur un servlet qui est câblée dans un domaine de sécurité fourni par le serveur d'applications. Le conteneur de servlet associera alors les requêtes HTTP entrantes à un principal utilisateur. Ce principal utilisateur doit être associé à un ou plusieurs «rôles» avant qu'un accès basé sur un rôle puisse être effectué (ce qui est fait de manière dépendante du fournisseur, mais souvent associé à JAAS).Si l'utilisateur n'a pas de rôle, le conteneur rejette toute tentative d'invocation de servlets ou d'EJB en aval protégés par des déclarations de rôle de sécurité dans les descripteurs de déploiement ou les annotations @javax.annotation.security.RolesAllowed associées. Le contexte de sécurité établi par le conteneur de servlet est propagé à travers la chaîne d'appels EJB suivante jusqu'à ce qu'il retourne avec succès ou soit bloqué par un rôle de sécurité.

Pour plus d'informations, reportez-vous aux chapitres "Sécurité" de la spécification de servlet et à la spécification EJB.