----- Original Message -----
From: "Keith L. Musser" <[EMAIL PROTECTED]>
To: "jBOSS-User" <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 7:28 PM
Subject: [jBoss-User] enhancing the EJB model
> I would like to be able to do some work which, to the best of my
> understanding, is not supported directly in the EJB model. If the EJB
> model supports these things, can someone point me to the right part of
> the spec. If not, does anyone else think these capabilities would be
> useful?
>
> Here is what I'd like to be able to do:
>
> (1) Periodically invoke a method on a bean. I would specify the period
> and the security context (caller principal) for the call in the
> deployment descriptor.
>
You could do this within the JBoss vm using a JMX MBean. Search the archives
for 'Security Walkthrough/How To/Tutorial, first cut' on a description of the
security that is currently available. The archive is at
http://www.mail-archive.com/[email protected]/
> The only way I know how to do this now is to have a client which calls
> the bean's method periodically. I can do this from outside of JBoss, or
> (cheating) by starting a thread from the bean's class when the first
> instance is created (presumably that would be when an instance is
> created to use for the "home" interface). Once the thread is started,
> it runs forever, calling a method periodically. I also have to shut
> down --perhaps when the last instance of the class is finalized.
>
> This would work, but I think it's not compliant with the EJB spec.
>
It is not.
> (2) I'd also like a "super-user" security context. By a "super-user"
> security context, I mean a security context in which the bean is able to
> change it's security association ("caller principal") programmatically
> for nested calls to other beans.
>
> That is, I'd like to do something like this...
> ...
> ctx.setCallerPrincipal( new_principal );
> bean.callMethod();
> ctx.resetCallerPrincipal();
> ...
>
> Of course, there's no "setCallerPrincipal" method in the EJBContext
> because normally that should not be allowed. I would want to allow it
> only if the current context is a "super-user" (which I leave undefined
> for now).
>
> This would be useful in my application because the logic in my beans
> depends heavily on user identity. (i.e. my entity beans define access
> controls based on "owner" and "group", like files in a filesystem,
> rather than based on "roles" as in the ordinary EJB security model.)
>
> Periodically I need to do work that may be on behalf of any user.
>
> Currently my work-around for these issues is to create a long-lived
> "client" application which sits outside of JBoss. It invokes methods
> periodically. And when necessary it changes it's security association
> to call another method. This "client" is, therefore, essential to the
> proper operation of my server.
>
> Sure, I can run the client thread in the same JVM as JBoss. But that's
> missing the point. Wouldn't it be useful for the EJB model to handle
> things like this?
>
> Keith L. Musser
> Integrated Dynamics, Inc.
> 812-371-7777
> email: [EMAIL PROTECTED]
>
This is a bigger issue. There have been and are a number of ongoing discussions
concerning
enchancing the security model in JBoss. The EJB security model is pretty weak as it
stands now.
I am working on a prototype that uses JAAS and a delegation model to allow for security
that is a function of the the bean or arguments passed to a bean method. It could
easily
support the runAs user behavior your looking for. It will probably be at least a week
before
I have even the preliminary prototype.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
