You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Quintin Beukes (JIRA)" <ji...@apache.org> on 2009/09/11 12:10:57 UTC

[jira] Created: (GERONIMO-4867) Compared to 2.1, 2.2 doesn't handle security realms created through the console the same

Compared to 2.1, 2.2 doesn't handle security realms created through the console the same
----------------------------------------------------------------------------------------

                 Key: GERONIMO-4867
                 URL: https://issues.apache.org/jira/browse/GERONIMO-4867
             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.

[jira] Closed: (GERONIMO-4867) Compared to 2.1, 2.2 doesn't handle security realms created through the console the same

Posted by "David Jencks (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/GERONIMO-4867
>             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.