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 <[email protected]> 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 <[email protected]> >> 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
