geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: Replacing the server-security-config plugin
Date Fri, 11 Sep 2009 19:15:03 GMT
I'm just going to take this route. Saves me from setting up all those
files myself.

Q

On Fri, Sep 11, 2009 at 9:04 PM, Quintin Beukes <quintin@skywalk.co.za> wrote:
> Sorry, I've never created a plugin. To create a new
> server-security-config plugin, do you mean I should copy
> server-security-config using the console's plugin export and modify
> it?
>
> Q
>
> On Fri, Sep 11, 2009 at 8:47 PM, Joe Dente <jdente@21technologies.com> wrote:
>> To reproduce it create your own server-security-config plugin that uses any login
module other than the properties-login gbean that is expected. You then need to deploy your
new server-security-config plugin and have it completely replace the default server-security-config
(see http://cwiki.apache.org/confluence/display/GMOxDOC22/Basic+Hints+on+Security+Configuration).
I achieved this by telling the server-security-config car to not load in the config.xml, telling
my security plugin to load in the config.xml, and then adding artifact aliases for both the
2.1.4 and wildcard-versioned lines referring to the server-security-config plugin in the artifact_aliases.properties
file.
>>
>> In artifact_alases.properties:
>>        org.apache.geronimo.framework/server-security-config//car=com.my.geronimo/my-security-config/1.0/car
>>        org.apache.geronimo.framework/server-security-config/2.1.4/car=org com.my.geronimo/my-security-config/1.0/car
>>
>> In config.xml:
>>        <module name="org.apache.geronimo.framework/server-security-config/2.1.4/car"
load="false"/>
>>        <module name="com.my.geronimo/my-security-config/1.0/car"/>
>>
>> Now try and startup Geronimo. You will see the error discussing the missing expected
gbean.
>> Hope this helps,
>> Joe
>>
>>
>>
>> -------------
>> Errr. Ouch. *rubbing the brused area in his brain*.
>>
>> I'm not that on with everything you said. I think the best thing would
>> be to reproduce it. What would I do to reproduce it?
>>
>> Q
>>
>> On Fri, Sep 11, 2009 at 6:42 PM, David Jencks <david_jencks@yahoo.com> wrote:
>>>
>>> On Sep 11, 2009, at 5:49 AM, Quintin Beukes wrote:
>>>
>>>> I'll be willing to have a look at it.
>>>>
>>>> can you give me a general idea what I'm supposed to look at and how it
>>>> would be done?
>>>
>>> IIRC the failure is caused by an unsatisfied single valued gbean reference
>>> to the properties login module gbean from something in the admin console.
>>>  You need to find the gbean reference and change it to a collection valued
>>> reference so it's no longer a mandatory reference.  You can wrap a
>>> collection valued reference with SingleElementCollection to make it act like
>>> an optional single valued reference.
>>>
>>> hope this is clear enough to help..
>>> david jencks
>>>
>>>>
>>>> Q
>>>>
>>>> On Fri, Sep 11, 2009 at 12:07 AM, David Jencks <david_jencks@yahoo.com>
>>>> wrote:
>>>>>
>>>>> Hi Joe!
>>>>> On Sep 10, 2009, at 2:18 PM, Joe Dente wrote:
>>>>>
>>>>> Hi,
>>>>> I've been working on replacing Geronimo 2.1.4's server-security-config
>>>>> plugin's example security with our own security plugin. We need single
>>>>> sign
>>>>> on for our application which also means the same sign on process has
to
>>>>> work
>>>>> with the Geronimo admin console. We need to be able to use custom realms
>>>>> and
>>>>> custom login modules in our server-security-config plugin replacement
>>>>> that
>>>>> may change depending on the environment we deploy to. I've run into two
>>>>> limitations so far that I've found documented online. One is that unless
>>>>> I
>>>>> want to re-deploy other plugins that use the 'geronimo-admin' security
>>>>> realm, than our custom security realm must be named 'geronimo-admin'
as
>>>>> well. The other is that I ran
>>>>> intohttp://issues.apache.org/jira/browse/GERONIMO-4603, forcing me to
>>>>> creating a dummy properties-login gbean in order for the tomcat
>>>>> components
>>>>> to start up.
>>>>>
>>>>> In my experience this is incredibly annoying.  I don't have time but
>>>>> wonder
>>>>> if anyone else can see about fixing this for 2.2.
>>>>>
>>>>>  I've created alias' for my plugin over the server-security-config plugin
>>>>> in
>>>>> 'artifact-aliases.properties' file and I've also disabled the
>>>>> server-security-config plugin and added my plugin as a loaded module
in
>>>>> the
>>>>> 'config.xml'. Unfortunately, I still cannot log into the Geronimo console
>>>>> using my custom security realm and login module. Geronimo has no problem
>>>>> starting with the current configuration and I can even login using my
>>>>> custom
>>>>> login module. Everything seems happy as far as the login process is
>>>>> concerned when I step through the code, but instead of seeing the
>>>>> Geronimo
>>>>> console I get a tomcat error page stating 'Access to the specified
>>>>> resource
>>>>> () has been forbidden'.  The logs are completely clean as well as the
>>>>> console output. My only idea is that my admin users also need to be
>>>>> members
>>>>> of a specifically named Geronimo admin group (make my admin groups name
>>>>> exactly match the one setup in the default security plugin)? I have not
>>>>> tested this hypothesis out yet, because I have my own admin group that
is
>>>>> used by our application that I would like to re-use as the Geronimo
>>>>> console's admin group. Any other thoughts?
>>>>>
>>>>> In 2.1.x you are stuck with the principal-role mapping in the ee
>>>>> application, although in 2.2 you can put it into a different plugin if
>>>>> you
>>>>> want and I think then swap it via an artifact-alias with one in a
>>>>> different
>>>>> plugin.
>>>>> So, that means that you need to supply the principals the principal-role
>>>>> mapping expects:
>>>>>    <security xmlns="http://geronimo.apache.org/xml/ns/security-1.2">
>>>>>        <role-mappings>
>>>>>            <role role-name="admin">
>>>>>                <principal
>>>>>
>>>>> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>>>>> name="admin" />
>>>>>            </role>
>>>>>        </role-mappings>
>>>>>    </security>
>>>>>
>>>>> So, your login module needs to supply a principal of
>>>>> class GeronimoGroupPrincipal and name "admin".
>>>>> Let us know if this doesn't work.
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Quintin Beukes
>>>
>>>
>>
>>
>>
>> --
>> Quintin Beukes
>>
>
>
>
> --
> Quintin Beukes
>



-- 
Quintin Beukes

Mime
View raw message