On Mon, 19 Mar 2001, David Bullock wrote:

Jim,

It seems like the issue is not so much a security issue as an application partitioning 
issue.  You don't wish non-approved *application components* accessing your 
components.  It has nothing to do with the access rights of the user using the 
facilities provided.

So the solution is to add a new dimension to security - 'component security' as 
opposed to 'user security'.

Maybe what is needed is an addition to the declarative properties of the deployment 
descriptor, to restrict access from certain 'authenticated application domains' ... 
plus a way of specifying which EJB's / clients may be in a particular application 
domain.  It would be up to the application server to decide which domain a given 
client belongs to.

Popular mechanisms to date on the web include:
- remote client's IP address
- remote client's DNS name

Obviously, in an enterpise setting, there would ideally be more flexible controls than 
these.

It is well worth petitioning the spec committee for this capability, since the basic 
design pattern of disallowing client access to an Entity except through a mediating 
Session is VERY IMPORTANT.  Got access to the committee?

Hope that gives you a starting point,
David.


On Sun, 18 Mar 2001, James Cook wrote:

> This topic surfaced recently on the jBoss mail list and I thought I would
> bring it over here as well.
>
> We are all aware that EJB provides us with declaritive security which will
> prevent clients (and EJBs) from accessing methods that they do not have
> rights to. We also use the facade pattern to shield our entity beans from
> direct access from clients. It may look like this:
>
> SSB1 -> EB1 -> EB2
>
> This serves a particular purpose, but it is rarely sufficent enough for many
> security needs. Perhaps the principal is allowed to transfer funds up to a
> certain amount, or they can initiate certain types of projects, but not
> others. This is where programmatic security steps in. EJB conveniently gives
> us the isUserInRole() method to determine if this user has sufficient rights
> to perform such actions.
>
> BUT, it seems that these rights conflict with each other. To shield a client
> from directly accessing EB1 or EB2 in the example above, the role assigned
> to methods on these beans must be racheted down. The session bean facade
> must relogin using these more restricted credentials in order to contact the
> entity beans. When this is done, the original credentials of the user are
> lost and the entity beans can no longer make an informed decision about our
> client's security roles!?
>
> What solutions exist? One may be to register the entity beans in a name
> server that the client cannot reach, however this would probably mean that
> the session bean would have to be separated from the entity beans it
> facades. Not a pretty design.
>
> jim
>
> ===========================================================================
> 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".
>
>





David Bullock
LISAsoft Project Lead
Sun Certified Programmer for the Java 2 Platform

 email: [EMAIL PROTECTED]
mobile: +61 4 0290 1228

"The key ingredients of success are a crystal-clear goal,
a realistic attack plan to achieve that goal,
and consistent, daily action to reach that goal."

Steve Maguire, "Debugging the Development Process".

LISAsoft
http://www.lisasoft.com/

Adelaide                  Sydney
--------------------      ------------------------
38 Greenhill Rd           Level 3, 228 Pitt Street
Wayville S.A. 5034        Sydney NSW 2000
Australia                 Australia

PH  +61 8 8272 1555       PH  +61 2 9283 0877
FAX +61 8 8271 1199       FAX +61 2 9283 0866
--------------------      ------------------------





David Bullock
LISAsoft Project Lead
Sun Certified Programmer for the Java 2 Platform

 email: [EMAIL PROTECTED]
mobile: +61 4 0290 1228

"The key ingredients of success are a crystal-clear goal,
a realistic attack plan to achieve that goal,
and consistent, daily action to reach that goal."

Steve Maguire, "Debugging the Development Process".

LISAsoft
http://www.lisasoft.com/

Adelaide                  Sydney
--------------------      ------------------------
38 Greenhill Rd           Level 3, 228 Pitt Street
Wayville S.A. 5034        Sydney NSW 2000
Australia                 Australia

PH  +61 8 8272 1555       PH  +61 2 9283 0877
FAX +61 8 8271 1199       FAX +61 2 9283 0866
--------------------      ------------------------

===========================================================================
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".

Reply via email to