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 <quin...@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 <jde...@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_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 >> > > > > -- > Quintin Beukes > -- Quintin Beukes
