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_jen...@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_jen...@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
