JB,
You should be able to achieve this with Principal delegation. In the 1.1 spec this is
mentioned but there are no deployment descriptor elements defined so this has
to be an app server dependent mechanism. In the 2.0 public draft deployment
descriptors are introduced for managing this.
Using this you could have your entity bean require a security-role that only your
session bean facade could assume.
+++ From EJB 1.1 spec:
15.4.3 Principal delegation
The Deployer is responsible for configuring the principal delegation for
inter-component calls. The
Deployer must follow any instructions supplied by the Application Assembler (for
example, provided in
the description elements of the deployment descriptor, or in a deployment manual).
The default mode is to propagate the caller principal from one component to another
(i.e. the caller principal
of the first enterprise bean in a call-chain is passed to the enterprise beans down
the chain). In the
absence of instructions from the Application Assembler, the Deployer should configure
the enterprise
beans such that this "caller propagation" mode is used when one enterprise bean calls
another. This
ensures that the returned value of getCallerPrincipal() will be the same for all the
enterprise
beans involved in a call chain.
+++ From EJB 2.0 PD draft:
20.4.3 Principal delegation
The Deployer is responsible for configuring the principal delegation for
inter-component calls. The
Deployer must follow any instructions supplied by the Application Assembler (for
example, provided in
the runAs-specified-identity elements of the deployment descriptor, in the description
elements of the deployment descriptor, or in a deployment manual).
If the use-caller-identity element is specified, the caller principal is propagated
from one com-ponent
to another (i.e. the caller principal of the first enterprise bean in a call-chain is
passed to the
enterprise beans down the chain). This ensures that the returned value of
getCallerPrincipal()
will be the same for all the enterprise beans involved in a call chain. Note that if
the security infrastruc-ture
performs principal mapping in the course of the call chain, however, the
getCallerPrincipal()
method returns the principal that is the result of the mapping, not the original
caller principal.
If the Application Assembler specifies that a runAs identity be used on behalf of a
particular enterprise
bean, the Deployer must configure the enterprise beans such that the runAs principal
is used as the caller
principal on any calls that the enterprise bean makes to other beans, and that the
runAs principal is prop-agated
along the call-chain of those other beans (in the absence of the specification of any
further
runAs-specified-identity elements).
----- Original Message -----
From: "Jean-Baptiste Nizet" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 16, 2000 4:38 AM
Subject: No access to some beans for the client
It's often a good design to have a session bean acting as a fa�ade to one or
several entity beans. This allows a good transactional behaviour, some
validations in the facade, additional security if needed, and more reusability
for the entity bean.
However, the entity bean sees its fa�ade session bean as any other client. Is
there a way to ensure that the bean (or some methods of the bean) is always
accessed through a fa�ade, and not directly from the client?
JB.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
