0 Replies Latest reply on Oct 28, 2002 7:40 AM by shorero

    Jetty CLIENT-AUTH works, but...

    shorero

      OK, I've gotten Jetty to properly trigger client-cert authentication. The key turns out to be to add
      true
      to the configuration of the SSL listener in jboss-service.xml. However, to get
      <auth-method>CLIENT-CERT</auth-method>
      to work from a web.xml file, I've got to do something about class org.jboss.jetty.security.JBossUserRealm. As it currently exists, it will not accept a credential that's anything but a string; in particular, it rejects the credential (I suspect a certificate array) passed when <auth-method>CLIENT-CERT</auth-method> appears in the web.xml file.

      So, my question for the JBoss develoopment gurus is the best way to approach this modification. I could simply hack into JBossUserRealm and make it do what I want, but I'm not sure that this would be compatible with whatever else is going on in JBoss development land. I'd rather extend JBossUserRealm to add the behavior I want. However, this would involve either extending class org.jboss.jetty.JBossWebApplicationContext, where the new JBossUserRealm is built, or modifying it so that we could parameterize use of either the standard JBossUserRealm or some extension of it. If I try to go the parameterization route, I'm not sure how/what to modify to specify a variant JBossUserRealm class and how JBossWebApplicationContext would pick up the parameter.

      So, I need suggestions from the developoment team on how to proceed:

      o Directly modify JBossUserRealm to accept non-strings as credentials and then send it to the official developers to get included in JBoss (I don't want to have to hack this code every time a new JBoss release comes out)?

      o Create a mechanism for specifying an extension to JBossUserRealm? If so, where (that is, what .xml file) should the extension be specified and what classes should I modify to properly process the specification of the extension?