geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Closed: (GERONIMO-4867) Compared to 2.1, 2.2 doesn't handle security realms created through the console the same
Date Tue, 27 Oct 2009 00:49:59 GMT


David Jencks closed GERONIMO-4867.

    Resolution: Won't Fix

This is definitely a problem and will be annoying for users that use secured ejbs from remote
clients, but we haven't fixed it yet and after 2.2 gets out the door we cant really change
the behavior of 2.2 security realms.  If you can think of a way to fix this after 2.2 is released
please let us know.

> Compared to 2.1, 2.2 doesn't handle security realms created through the console the same
> ----------------------------------------------------------------------------------------
>                 Key: GERONIMO-4867
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: console, security
>    Affects Versions: 2.2
>            Reporter: Quintin Beukes
>             Fix For: 2.2
> In 2.1, when adding a security realm through the console, they were created as Global
realms. So you could log in via OpenEJB remotely without problems.
> If you were to upgrade to 2.2, you can't continue doing this if you deploy the old realm
file, because in 2.2 there is a "Global" parameter for a security realm which defaults to
false. So "upgrading" to 2.2, means deploying the same application, and when doing this your
application won't work if you use this functionality.
> You would get a "No LoginModules defined for realm XXX" exception, which means the realm
isn't found. 
> So this would create problems for people.
> I Suggest two options
> 1. If the global attribute is absent, default to "true"
> 2. When doing a remote login via OpenEJB, treat all realms as global. In other words
a remote login as access to all realms. People upgrading will still get the same behaviour,
and their old deploy plans will still allow their applications to work. This seems fine, because
there isn't a way for you to define dependencies on a remote client anyway, so treating all
realms as global seems fine. This might be considered bad practice, since the global attribute
is meant to close of realms from other people.
> Not really sure what the philosophies are around this, so I can't say which is best.
I would personally prefer the first option, as it allows one to still isolate realms. And
if you find that a realm is global, which you wouldn't have wanted so, it's as easy as redeploying
it to fix it.
> I definitely suggest that this be addressed before 2.2's release, as it will create bad
first impressions. One should always provide for all scenarios to make the end user experience
as comfortable as possible.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message