Possible Bug in Geronimo when doing remote login with OpenEJB RemoteInitialContextFactory

[Q Beukes]

Hey,

Is this a bug, or did something change I don't know of? Note that it
is 2.2, so it could most definitely be either. The code didn't change.
I only changed my JAR files and installed the new server. previously
all this worked.

Either way. I define a security realm called KMSRealm. i test it with
a WAR and EJB and login+authorization works fine. So it seems to work.

But as soon as I test it with a remote OpenEJB client it doesn't work.
I initialize the context factory as so:
    p.put("java.naming.factory.initial",
"org.apache.openejb.client.RemoteInitialContextFactory");
    p.put("java.naming.provider.url", "ejbd://localhost:4201");
    p.put("openejb.authentication.realmName", "KMSRealm");
    p.put("java.naming.security.principal", "quintin");
    p.put("java.naming.security.credentials", "pass");
    InitialContext ctx = new InitialContext(p);

Then I get this\. This is usually the error you get when a Realm isn't
found. Can someone please advice what could have gone wrong so I can
fix it. Thanks.

Exception in thread "main" javax.naming.AuthenticationException: This
principle is not authorized. [Root exception is
javax.security.auth.login.LoginException: No LoginModules configured
for KMSRealm]
        at org.apache.openejb.client.JNDIContext.authenticate(JNDIContext.java:188)
        at org.apache.openejb.client.JNDIContext.getInitialContext(JNDIContext.java:129)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
        at javax.naming.InitialContext.init(InitialContext.java:223)
        at javax.naming.InitialContext.<init>(InitialContext.java:197)
        at net.kunye.test.Main.main(Main.java:37)
Caused by: javax.security.auth.login.LoginException: No LoginModules
configured for KMSRealm
        at javax.security.auth.login.LoginContext.init(LoginContext.java:256)
        at javax.security.auth.login.LoginContext.<init>(LoginContext.java:499)
        at org.apache.geronimo.security.ContextManager.login(ContextManager.java:92)
        at org.apache.geronimo.security.ContextManager.login(ContextManager.java:108)
        at org.apache.geronimo.openejb.GeronimoSecurityService.login(GeronimoSecurityService.java:53)
        at org.apache.openejb.server.ejbd.AuthRequestHandler.processRequest(AuthRequestHandler.java:56)
        at org.apache.openejb.server.ejbd.EjbDaemon.processAuthRequest(EjbDaemon.java:204)
        at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:157)
        at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
        at org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
        at org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
        at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
        at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
        at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

--
Quintin Beukes

[Q Beukes]

I found this problem, and it's neither in OpenEJB 3.1.2 not Geronimo
2.2. It was in fact a changed feature.

There is a new gbean attribute called "global", which defaults to
false. Maybe this should default to "true", so as not to break the
programs of people upgrading? It took me hours to figure this out.
Imagine how long other less-determined folks would take, or would they
just give up?

Q

On Thu, Sep 10, 2009 at 2:20 PM, Quintin Beukes <quintin@...> wrote:

> Hey,
>
> Is this a bug, or did something change I don't know of? Note that it
> is 2.2, so it could most definitely be either. The code didn't change.
> I only changed my JAR files and installed the new server. previously
> all this worked.
>
> Either way. I define a security realm called KMSRealm. i test it with
> a WAR and EJB and login+authorization works fine. So it seems to work.
>
> But as soon as I test it with a remote OpenEJB client it doesn't work.
> I initialize the context factory as so:
>    p.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
>    p.put("java.naming.provider.url", "ejbd://localhost:4201");
>    p.put("openejb.authentication.realmName", "KMSRealm");
>    p.put("java.naming.security.principal", "quintin");
>    p.put("java.naming.security.credentials", "pass");
>    InitialContext ctx = new InitialContext(p);
>
> Then I get this\. This is usually the error you get when a Realm isn't
> found. Can someone please advice what could have gone wrong so I can
> fix it. Thanks.
>
> Exception in thread "main" javax.naming.AuthenticationException: This
> principle is not authorized. [Root exception is
> javax.security.auth.login.LoginException: No LoginModules configured
> for KMSRealm]
>        at org.apache.openejb.client.JNDIContext.authenticate(JNDIContext.java:188)
>        at org.apache.openejb.client.JNDIContext.getInitialContext(JNDIContext.java:129)
>        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
>        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
>        at javax.naming.InitialContext.init(InitialContext.java:223)
>        at javax.naming.InitialContext.<init>(InitialContext.java:197)
>        at net.kunye.test.Main.main(Main.java:37)
> Caused by: javax.security.auth.login.LoginException: No LoginModules
> configured for KMSRealm
>        at javax.security.auth.login.LoginContext.init(LoginContext.java:256)
>        at javax.security.auth.login.LoginContext.<init>(LoginContext.java:499)
>        at org.apache.geronimo.security.ContextManager.login(ContextManager.java:92)
>        at org.apache.geronimo.security.ContextManager.login(ContextManager.java:108)
>        at org.apache.geronimo.openejb.GeronimoSecurityService.login(GeronimoSecurityService.java:53)
>        at org.apache.openejb.server.ejbd.AuthRequestHandler.processRequest(AuthRequestHandler.java:56)
>        at org.apache.openejb.server.ejbd.EjbDaemon.processAuthRequest(EjbDaemon.java:204)
>        at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:157)
>        at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>        at org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:213)
>        at org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233)
>        at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>        at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:91)
>        at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:120)
>        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>        at java.lang.Thread.run(Thread.java:595)
>
> --
> Quintin Beukes
>

--
Quintin Beukes

[djencks]

On Sep 10, 2009, at 7:42 AM, Quintin Beukes wrote:

> I found this problem, and it's neither in OpenEJB 3.1.2 not Geronimo
> 2.2. It was in fact a changed feature.
>
> There is a new gbean attribute called "global", which defaults to
> false. Maybe this should default to "true", so as not to break the
> programs of people upgrading? It took me hours to figure this out.
> Imagine how long other less-determined folks would take, or would they
> just give up?

That's certainly a danger.  Do you think we could solve this with  
documentation?  The non-global realms interfere less with each other  
so I think they make a better default.  Any other opinions?

thanks
david jencks

>
> Q
>
> On Thu, Sep 10, 2009 at 2:20 PM, Quintin Beukes  
> <quintin@...> wrote:
>> Hey,
>>
>> Is this a bug, or did something change I don't know of? Note that it
>> is 2.2, so it could most definitely be either. The code didn't  
>> change.
>> I only changed my JAR files and installed the new server. previously
>> all this worked.
>>
>> Either way. I define a security realm called KMSRealm. i test it with
>> a WAR and EJB and login+authorization works fine. So it seems to  
>> work.
>>
>> But as soon as I test it with a remote OpenEJB client it doesn't  
>> work.
>> I initialize the context factory as so:
>>    p.put("java.naming.factory.initial",
>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>    p.put("java.naming.provider.url", "ejbd://localhost:4201");
>>    p.put("openejb.authentication.realmName", "KMSRealm");
>>    p.put("java.naming.security.principal", "quintin");
>>    p.put("java.naming.security.credentials", "pass");
>>    InitialContext ctx = new InitialContext(p);
>>
>> Then I get this\. This is usually the error you get when a Realm  
>> isn't
>> found. Can someone please advice what could have gone wrong so I can
>> fix it. Thanks.
>>
>> Exception in thread "main" javax.naming.AuthenticationException: This
>> principle is not authorized. [Root exception is
>> javax.security.auth.login.LoginException: No LoginModules configured
>> for KMSRealm]
>>        at  
>> org.apache.openejb.client.JNDIContext.authenticate(JNDIContext.java:
>> 188)
>>        at  
>> org
>> .apache
>> .openejb.client.JNDIContext.getInitialContext(JNDIContext.java:129)
>>        at  
>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:
>> 667)
>>        at  
>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:
>> 288)
>>        at javax.naming.InitialContext.init(InitialContext.java:223)
>>        at javax.naming.InitialContext.<init>(InitialContext.java:197)
>>        at net.kunye.test.Main.main(Main.java:37)
>> Caused by: javax.security.auth.login.LoginException: No LoginModules
>> configured for KMSRealm
>>        at  
>> javax.security.auth.login.LoginContext.init(LoginContext.java:256)
>>        at  
>> javax.security.auth.login.LoginContext.<init>(LoginContext.java:499)
>>        at  
>> org
>> .apache.geronimo.security.ContextManager.login(ContextManager.java:
>> 92)
>>        at  
>> org
>> .apache.geronimo.security.ContextManager.login(ContextManager.java:
>> 108)
>>        at  
>> org
>> .apache
>> .geronimo
>> .openejb.GeronimoSecurityService.login(GeronimoSecurityService.java:
>> 53)
>>        at  
>> org
>> .apache
>> .openejb
>> .server
>> .ejbd.AuthRequestHandler.processRequest(AuthRequestHandler.java:56)
>>        at  
>> org
>> .apache
>> .openejb.server.ejbd.EjbDaemon.processAuthRequest(EjbDaemon.java:204)
>>        at  
>> org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:157)
>>        at  
>> org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:71)
>>        at org.apache.openejb.server.ejbd.KeepAliveServer
>> $Session.service(KeepAliveServer.java:213)
>>        at  
>> org
>> .apache
>> .openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:
>> 233)
>>        at  
>> org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66)
>>        at org.apache.openejb.server.ServicePool
>> $2.run(ServicePool.java:91)
>>        at org.apache.openejb.server.ServicePool
>> $3.run(ServicePool.java:120)
>>        at java.util.concurrent.ThreadPoolExecutor
>> $Worker.runTask(ThreadPoolExecutor.java:650)
>>        at java.util.concurrent.ThreadPoolExecutor
>> $Worker.run(ThreadPoolExecutor.java:675)
>>        at java.lang.Thread.run(Thread.java:595)
>>
>> --
>> Quintin Beukes
>>
>
>
>
> --
> Quintin Beukes

[Juergen Weber]

What about a hint in the Exception message? This is the first thing one reads if something goes wrong, much earlier than documentation.

Greetings, Juergen

djencks wrote:

That's certainly a danger.  Do you think we could solve this with  
documentation?  The non-global realms interfere less with each other  
so I think they make a better default.  Any other opinions?

thanks
david jencks

[Quintin Beukes-2]

Sorry, missed the message.

As I suggested on the
ticket(https://issues.apache.org/jira/browse/GERONIMO-4867), that a
good default for an "absent" option is to have it global. Which is the
same behaviour as previously.

A problem with documentation is that people don't always read the
"upgrade docs" before the "upgrade". it's good practice, but rarely
done, and one should try and make all user's experiences comfortable.

I think doing all the following should do the trick. They are changes
in UI as well as behaviour. People get used to doing things in a
certain way, and if they do their 'things' and it doesn't work, sure
it's their fault but it still makes their life more difficult and
their experience of Geronimo more unpleasant. Successful software
usually design around these points of failure to provide for all kinds
of users/situations so their experiences are more of a smooth ride.
Further, to make it more clear what has gone wrong when it DOES happen
(like when they use a deployment plan which worked perfectly with
Geronimo 2.1), the following helps out with that as well.

- Purely when the attribute is absent, thus NULL (compared to
true/false), fail the deploy (required attribute) and show a message
similar to the following: "Since Geronimo 2.2, the 'global' realm
attribute is required. See
<http://localhost:8080/console/global-attribute-update.html> for
details". I think hosting it in the localhost helps for those people
who deploy in situations where they don't have the internet. Rare?
Even necessary? It does happen though. I've done deployments 3KM
underground, and then you are very far away from the net.
- When you try to connect to a realm which exists, but is not global,
don't show "No LoginModules defined", rather say something like "Realm
'mySecurityRealm' is not global"
- When creating a security realm through the console, move the
"Global" option to the top of the list (it helps it being noticed).
Alternatively add a *new to it (which might look a bit corny).
- How about branching out from the start. Instead of doing an "Add New
Security Realm" on the realms listing, split it into 2 options, ie.
"Add new Local Realm", "Add new Global Realm".

Q

On Thu, Sep 10, 2009 at 8:34 PM, Juergen Weber <weberjn@...> wrote:

>
> What about a hint in the Exception message? This is the first thing one reads
> if something goes wrong, much earlier than documentation.
>
> Greetings, Juergen
>
>
>
> djencks wrote:
>>
>> That's certainly a danger.  Do you think we could solve this with
>> documentation?  The non-global realms interfere less with each other
>> so I think they make a better default.  Any other opinions?
>>
>> thanks
>> david jencks
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Possible-Bug-in-Geronimo-when-doing-remote-login-with-OpenEJB--RemoteInitialContextFactory-tp25382312s134p25388718.html
> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>
>

--
Quintin Beukes

[Quintin Beukes-2]

Re. hosting it on localhost, maybe we should put the "friendly"
changelog on the localhost. And even provide a link from the login
page and once logged in the welcome page.

This changelog can then document everything that changed, including
things that make your life easier, changes in behaviour (like the
problem we're discussing), changes in UI (things that are
added/moved/removed), etc.

It makes it more accessible, and errors like this one can refer to it.
Then further, anything on the console that's new can have a little [*]
link next to it, which links to it's item in the changelog.

Q

On Fri, Sep 11, 2009 at 3:04 PM, Quintin Beukes <quintin@...> wrote:

> Sorry, missed the message.
>
> As I suggested on the
> ticket(https://issues.apache.org/jira/browse/GERONIMO-4867), that a
> good default for an "absent" option is to have it global. Which is the
> same behaviour as previously.
>
> A problem with documentation is that people don't always read the
> "upgrade docs" before the "upgrade". it's good practice, but rarely
> done, and one should try and make all user's experiences comfortable.
>
> I think doing all the following should do the trick. They are changes
> in UI as well as behaviour. People get used to doing things in a
> certain way, and if they do their 'things' and it doesn't work, sure
> it's their fault but it still makes their life more difficult and
> their experience of Geronimo more unpleasant. Successful software
> usually design around these points of failure to provide for all kinds
> of users/situations so their experiences are more of a smooth ride.
> Further, to make it more clear what has gone wrong when it DOES happen
> (like when they use a deployment plan which worked perfectly with
> Geronimo 2.1), the following helps out with that as well.
>
> - Purely when the attribute is absent, thus NULL (compared to
> true/false), fail the deploy (required attribute) and show a message
> similar to the following: "Since Geronimo 2.2, the 'global' realm
> attribute is required. See
> <http://localhost:8080/console/global-attribute-update.html> for
> details". I think hosting it in the localhost helps for those people
> who deploy in situations where they don't have the internet. Rare?
> Even necessary? It does happen though. I've done deployments 3KM
> underground, and then you are very far away from the net.
> - When you try to connect to a realm which exists, but is not global,
> don't show "No LoginModules defined", rather say something like "Realm
> 'mySecurityRealm' is not global"
> - When creating a security realm through the console, move the
> "Global" option to the top of the list (it helps it being noticed).
> Alternatively add a *new to it (which might look a bit corny).
> - How about branching out from the start. Instead of doing an "Add New
> Security Realm" on the realms listing, split it into 2 options, ie.
> "Add new Local Realm", "Add new Global Realm".
>
> Q
>
> On Thu, Sep 10, 2009 at 8:34 PM, Juergen Weber <weberjn@...> wrote:
>>
>> What about a hint in the Exception message? This is the first thing one reads
>> if something goes wrong, much earlier than documentation.
>>
>> Greetings, Juergen
>>
>>
>>
>> djencks wrote:
>>>
>>> That's certainly a danger.  Do you think we could solve this with
>>> documentation?  The non-global realms interfere less with each other
>>> so I think they make a better default.  Any other opinions?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Possible-Bug-in-Geronimo-when-doing-remote-login-with-OpenEJB--RemoteInitialContextFactory-tp25382312s134p25388718.html
>> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Quintin Beukes
>

--
Quintin Beukes