MDB security again

[uuu]

Hi!
I got a problem with MDB security.
I wanna call a session bean from onMessage and that session bean is secured.
So I placed <run-as> onto my MDB and in jboss.xml I configured it for using the same JASS realm as the session bean.
All I get is Bad password for username=null.
I've searched through the JBoss forums and docs and found the tip that says to put unauthenticatedIdentity in my login-config.xml.
But why should I use such an ugly thing? Why should I rely upon unauthenticatedIdentity?
Is this a feature I dont't understand?
I'd better like to have MDB configured with some concrete user.
And I did so by using <mdb-user> but it didn't help.
And what about <run-as> feature in Session and Entity beans?
Please help me, I guess it's not only me who hungers for more clean understanding of all this.
Alexander

[adrian.brock]

<run-as> refers to the authorities.

You still need an authentication.

Just create a user with no roles for the unauthenicated
identity - that way if somebody uses that identity
for authentication they won't be authorised to do anything.

The MDB is ok because it is using the <run-as> authorities.

Regards,
Adrian

[atomray]

Hi,

Like other people who have posted questions on this topic, I'm attempting to have my MDB call a session EJB that has a security constraint. I specify the run-as, but that did not permit me to interact with the session bean - it would not be authorized as the principal is null.

After reading messages in the JBoss forums, I added an unauthenticated identity, with a user that had no roles. This did not correct the problem, the principal remained null. After further searching, I found a code snippet that did a JAAS login in the MDB onMessage() method. I logged in as my guest user and was finally able to invoke my session bean's methods.

I don't believe I'm doing this correctly, although I managed to make it work. Is all this strictly necessary, or is there a more simple way to achieve this?

Thanks for your help,
Adam

[adrian.brock]

Your problem is a security configuration issue not an mdb
issue.

Your unauthenticated identity is not configured correctly if it still
complaining about a null principal.

Regards,
Adrian