jboss-mx guys, more on interceptors - in light of Juha's boo

[squirest]

Ok,

I've got the book and skimmed for the relevant parts to see where Juha's head is at. I've also been thinking about the JSR160 abstract.

Note that I'm not trying to implement JSR160 from the abstract or anything. However, features listed in the abstract *are* being talked about for JBossMX.

Anyhow, I think my head might be in a different place from Juha and the JSR160 guys so I'm looking for some clarification.

looking at the JSR160 abstract it says it will define:

MBean Interceptor interfaces, providing a mean to insert functionality, such as security or monitoring components, into the invocation path between the JMX Agent and MBeans (similar to CORBA pattern).

So interceptors are coming as part of the spec.

Obviously, just which calls pass through the "invocation chain" is not published yet.

Given that they say "interfaces" I think it's unlikely that the interceptors will maintain a reference to its next interceptor.

It also seems likely that a third party may configure the interceptor chain for a given MBean. My best guess is that you'd invoke a setInterceptors(ObjectName name, ObjectName[] interceptornames) style method on an MBean sitting in the JMImplementation domain.

(side to juha, yes I know that causes a problem for XMBean configured interceptors but bear with me)

The biggest issue for me is what calls are interceptable?

On the one hand I think *everything* that is called via the MBeanServer goes through the interceptable invocation chain. This includes DynamicMBean, NotificationBroadcaster and (I think) NotificationListener.

On the other hand this might be dangerous. For example, if getMBeanInfo goes through interceptors then someone could modify the MBeanInfo on the way out.

Other hints in the current spec and in Juhas book indicate that the accepted interpretation of "invocation path" might be *just* the DynamicMBean invoke() method.

The more I code this the more I turn into a bistable multivibrator (flip-flop). Yesterday it was "intercept everything".

Today I *really* like "only intercept DynamicMBean.invoke()". To me, that's the only call which makes sense to have an external entity processing (juha, your strategy for ModelMBeans is a special case).

Ok, that's my opinion. Now, what's the truth?

Trev

[adrian.brock]

Hi Trevor,

I think you need a security interceptor for
get/setAttribute.

And since you can get cached attribute values
from the getMBeanInfo() you'll need one there as well.

What's wrong with a security interceptor filtering
getMBeanInfo according to the role of caller?
e.g. Don't even tell them about operations they can't use.

Regards,
Adrian

[squirest]

> I think you need a security interceptor for
> get/setAttribute.

That's true. I can also see a requirement for security checks on addNotificationListener too.

Obviously (and this is something I didn't mention in my original post) the ability for a third-party to configure the interceptor (whatever "invocation path" turns out to be) chain on an MBean would need to be access controlled.

> And since you can get cached attribute values
> from the getMBeanInfo() you'll need one there as
> well.

Ok, that caching is only courtesy of ModelMBeans though right? If that caching via interceptors (as Juha has coded it now) they would be private, behind the ModelMBean anyway. As such, not third-party settable.

> What's wrong with a security interceptor filtering
> getMBeanInfo according to the role of caller?
> e.g. Don't even tell them about operations they can't
> use.

That's an interesting question. I'm not sure other than it sounds like more trouble than it's worth despite being kinda cool.

Hmmm... thinking, thinking.
Trev

[squirest]

Still not 100% convinced.

The security examples seem more related to agent (MBeanServer) permissions than MBean permissions. I.e. can you register an MBean, can you call invoke or get/setAttribute.

Maybe it's because I'm imagining permissions like "setAttribute, *:*,type=FooComponent". I don't see permissions which effectively say "the poweruser role can read all attributes and write the wibbleTime attribute while the admin role can read and write all attributes".

That's probably why I can't help but think there are better ways to enforce security at an agent level than to optionally configure a security interceptor on each bean. After a point I think you'll have so many configured security interceptors (or references to a couple of interceptors) that it may have just been easier to secure the MBeanServer itself.

Aside from security, another popular example of an "interceptor" is logging/metrics. However, JMX is chock full of ways to do that in a JMX manner and I don't think we need to introduce another way.

I'm afraid I'm still left thinking that the only type of thirdparty interceptor someone will want to take advantage of (ok, that someone is me right now) is a domain specific one so that alters an invocation's context. Back to DynamicMBean.invoke().

Yes, domain specific interceptors will probably include role-based operation-granular security enforcers. Somehow I don't have a problem with that.

Sigh.
Trevor

[squirest]

Ok I slept on it and decided that interpreting "invocation chain" as DynamicMBean, NotificationBroadcaster and NotificationListener is ok. Ultimately it came down to a question of why hobble it just because I'm not able to see all the valid uses.

By the way Adrian, thanks for the input.
Trev