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?
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
