JBossWeb, or may be rather the Tomcat integration code (in JBossAs trunk/tomcat) does not seem to be capable of injecting custom attributes into Valves instances. Example, I have a context configuration with a Valve element having few attributes meant to customize the way this Valve will work, but I never see the properties injected. There's the code there which is supposed to inject the attribute values, ex, in TomcatService : if (metaData.getAttributes() != null) { Iterator<QName> names = metaData.getAttributes().keySet().iterator(); while (names.hasNext()) { QName name = names.next(); String value = (String) metaData.getAttributes().get(name); // FIXME: This should be done by XB value = StringPropertyReplacer.replaceProperties(value); IntrospectionUtils.setProperty(instance, name.getLocalPart(), value); } } As it happens a metaData instance has no attributes despite them being available in the configuration, ex : <Context> <Valve className="someClass" a="b"/> </Context> but the className is actually retrieved and is not null. This makes me think the unmarshalling does not work earlier on in JBossContextConfig.processContextConfig : SchemaBinding schema = JBossXBBuilder.build(ContextMetaData.class); Unmarshaller u = UnmarshallerFactory.newInstance().newUnmarshaller(); .... contextMetaData = ContextMetaData.class.cast(u.unmarshal(is, schema)); Am I missing something ? Has anyone written a custom Valve with attributes being provided in the config, running on top of JBossWeb before ? thanks, Sergey ----- "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; wrote: > Forget Tomcat4 and 5 public api for AuthenticatorBase. > > They changed the API to cater to Servlet3 recently. Since > AuthenticatorBase is a > Tomcat interface, they can get away. > > Server binding code is always at the risk of internal api changing > over > major versions. > > On 08/25/2010 06:17 AM, Sergey Beryozkin wrote: > > Just FYI, org.apache.catalina.authenticator.AuthenticatorBase > shipped with > > JBossWeb (3.0-Beta5 and the one used in JBossAS built from the > trunk) does not match > > any of the Tomcat AuthenticatorBase classes documented publicly, at > least since Tomcat 4.0 > > > > JBossWeb expects that an abstract AuthenticatorBase.authenticate > method has the following signature : > > > > protected abstract boolean > authenticate(org.apache.catalina.connector.Request request, > > > javax.servlet.HttpServletResponse response, > > > org.apache.catalina.deploy.LoginConfig config) throws IOException; > > > > cheers, Sergey > > > > > > ----- "Sergey Beryozkin&quot;&lt;sberyozk(a)redhat.com&gt; wrote: > > > >> Thanks for the links. > >> > >> I checked a JBossAS Tomcat integration module earlier on, > >> at https://svn.jboss.org/repos/jbossas/tomcat > >> > >> and saw the references to jbossweb on forums, but still thought > >> catalina.jar was used somehow internally, thus was curious what > the > >> corresponding version was. > >> > >> At the moment I'm just doing a 'provided' scope dependency on > catalina > >> 6.0.28, and I'm assuming it will just work in JBoss but I guess > the > >> demo will be better off with depending on jbossweb. > >> > >> cheers, Sergey > >> > >> ----- "Brian Stansberry&quot;&lt;brian.stansberry(a)redhat.com&gt; wrote: > >> > >>> JBoss AS uses JBoss Web (derived from Tomcat), not Tomcat itself. > >>> > >>> > >> > https://repository.jboss.org/nexus/content/repositories/public-jboss/org/... > >>> is the location of the version currently used in AS trunk. > >>> > >>> > https://svn.jboss.org/repos/jbossas/trunk/component-matrix/pom.xml > >> is > >>> the file in the AS trunk that defines that dependency. > >>> > >>> On 7/15/10 10:23 AM, Sergey Beryozkin wrote: > >>>> Well, this is quite obvious, I can quess that one :-) > >>>> Which version of Catalina ? Though probably any in the 5.x range > >>> will do, just not sure if AS 6.0 uses Catalina 6.x or not > >>>> Cheers, Sergey > >>>> > >>>> ----- "Anil Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com&gt; wrote: > >>>> > >>>>> Sergey, > >>>>> extend Tomcat AuthenticatorBase class for your > authenticator. > >>> It > >>>>> should have available in the catalina jar. > >>>>> > >>>>> Cheers. > >>>>> > >>>>> On 07/15/2010 09:20 AM, Sergey Beryozkin wrote: > >>>>>> Hi Anil > >>>>>> > >>>>>> > >>>>>> ----- "Anil Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com&gt; wrote: > >>>>>> > >>>>>> > >>>>>>> The login modules happen late in the container security > >> sequence > >>>>> and > >>>>>>> have limited access to the network message etc. They can > only > >>> say > >>>>>>> yes/no to authentication. But they cannot do some of the > >>> redirects > >>>>> or > >>>>>>> other extra steps that are needed in mechanisms outside of > the > >>>>> servlet > >>>>>>> spec mechanisms (form, client-cert, basic,digest). SAML, > >>>>>>> OpenID/OAuth > >>>>>>> etc may need access to the network message (http message) and > >>> may > >>>>> have > >>>>>>> to redirect the request to an external identity provider. In > >>>>> these > >>>>>>> situations, you do container integration (in the case of > >> tomcat, > >>> it > >>>>> is > >>>>>>> via authenticators). > >>>>>>> > >>>>>>> Ideally, you should be doing JSR-196 which will provide you > the > >>>>>>> pluggable server authentication modules and can stack modules > >>> just > >>>>> as > >>>>>>> you do with login modules. > >>>>>>> > >>>>>>> We have support for JSR-196 in AS6 which needs to be taken > >>> further > >>>>>>> before EE6 certification. > >>>>>>> http://anil-identity.blogspot.com/search/label/jsr-196 > >>>>>>> > >>>>>>> > >>>>>> thanks for all the info, I will experiment with Athenticators, > >> no > >>>>> redirection will be needed in cases where they should > >>>>>> enforce that a given OAuth consumer is a valid one, but I'd > like > >>> to > >>>>> try them too... > >>>>>> How to figure out which catalina/tomcat dependency should be > >> used > >>>>> for writing a custom Authenticator to be used in JBossAS 6.0 > >>>>> deployments ? > >>>>>> thanks, Sergey > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 07/14/2010 11:17 AM, Sergey Beryozkin wrote: > >>>>>>> > >>>>>>>> Hi > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> For OAuth there are a few issues: > >>>>>>>>> > >>>>>>>>> 1. It has specific headers. > >>>>>>>>> 2. You create "secrets" on the fly which are used to > >>>>> authenticate > >>>>>>> and > >>>>>>> > >>>>>>>>> authorize requests. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Regarding 2: This is just one approach which the RestEasy > >>>>>>>> > >>>>>>> oauth-push-messaging takes, but one can imagine > >>>>>>> > >>>>>>>> the administrator registering the OAuth consumers > representing > >>>>> say > >>>>>>> messaging services in advance. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Maybe its best to first iterate on an Authenticator, then > >> move > >>>>>>> logic > >>>>>>> > >>>>>>>>> up > >>>>>>>>> the stack once you get a prototype going? I don't know how > >>>>> Sergey > >>>>>>>>> likes > >>>>>>>>> to work :) > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Well, my own problem so far is that I doubt the necessity of > >>>>>>>> > >>>>>>> introducing a role-based > >>>>>>> > >>>>>>>> control access in a push-messaging case given the way the > >>> current > >>>>>>> solution works. > >>>>>>> > >>>>>>>> Specifically, a subscriber needs to grant the messaging > >> service > >>> a > >>>>>>> permission to access a destination URI using a (domain) > >>>>> admin-level > >>>>>>> invocation on the message receiver; in other words the > >>> subscriber > >>>>> can > >>>>>>> not just tell the messaging service to push to some arbitrary > >>>>> server, > >>>>>>> the subscriber needs to control that specific URI space on > that > >>>>>>> server; it is really the subscriber's space in the end of the > >>> day. > >>>>>>>> So it is an admin-level decision which is enforced by the > >> OAuth > >>>>>>> filter anyway - by authenticating (by ensuring current OAuth > >>>>> client_id > >>>>>>> matches the records and checking the signature the secret) > and > >>>>>>> validating that the request URI matches the one specified by > >> the > >>>>> admin > >>>>>>> (subscriber) at the previous step. > >>>>>>> > >>>>>>>> Thus it is not obvious to me why it is worth introducing > >>> another > >>>>>>> authorization layer, at least given the way the > push-messaging > >>>>> demo > >>>>>>> works at the moment. And when I'm in doubt I'm really working > >>> very > >>>>>>> slowly, sorry, probably not a good thing to say publicly :-) > >>>>>>> > >>>>>>>> Where I can see the login modules may be introduced is when > we > >>>>> have > >>>>>>> OAuth consumers registered well in advance and say the > >>>>> administrator > >>>>>>> allocates roles to various consumers using nice UI and then > we > >>> have > >>>>> a > >>>>>>> case where some consumers may access one (resource) service > >>> method > >>>>> and > >>>>>>> some other consumers can access some other method only. It is > >>> not > >>>>> the > >>>>>>> case with the push-messaging demo though. > >>>>>>> > >>>>>>>> cheers, Sergey > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Chris Bredesen wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Yes. > >>>>>>>>>> > >>>>>>>>>> Authenticator is a Catalina/Web construct that delegates > to > >> a > >>>>>>> Realm > >>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>>> (Catalina construct) that, in JBAS is backed by > LoginModules > >>>>>>>>>> > >>>>>>> (JAAS > >>>>>>> > >>>>>>>>>> constructs, JBoss implementations). > >>>>>>>>>> > >>>>>>>>>> JAAS LoginModules are constrained by their own API which > >>> means > >>>>>>> they > >>>>>>> > >>>>>>>>>> > >>>>>>>>> get > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> access to only certain callbacks (username, password, etc) > >>> and > >>>>>>> have > >>>>>>> > >>>>>>>>>> > >>>>>>>>> no > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> knowledge of the Servlet API. You can do authentication > in > >>> an > >>>>>>>>>> Authenticator but that's not portable to other > >> non-Tomcat/JBW > >>>>>>>>>> environments. The naming is a bit confusing IMO. It made > >>>>> sense > >>>>>>> for > >>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Tomcat but adds confusion in JBAS. > >>>>>>>>>> > >>>>>>>>>> You don't need to worry about writing an Authenticator > >> unless > >>>>> you > >>>>>>>>>> > >>>>>>>>> need > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> access to something that you don't already get from the > >>>>> existing > >>>>>>>>>> Authenticators, such as cookies, etc. > >>>>>>>>>> > >>>>>>>>>> -CB > >>>>>>>>>> > >>>>>>>>>> On 07/14/2010 10:53 AM, Bill Burke wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Just guessing, > >>>>>>>>>>> > >>>>>>>>>>> Isn't the login module responsible for the actual > >>>>> authentication > >>>>>>>>>>> > >>>>>>>>> and > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> authorization? Tomcat authenticator is just responsible > >> for > >>>>>>>>>>> > >>>>>>>>> extracting > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> header info? > >>>>>>>>>>> > >>>>>>>>>>> Sergey Beryozkin wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Hi > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> You can achieve by writing a tomcat authenticator and > >>>>> putting > >>>>>>> it > >>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> in > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> WEB-INF/context.xml (JBAS) or META-INF/context.xml > >>> (tomcat). > >>>>>>>>>>>>> The auth-name is a string defined in the servlet spec. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> thanks for the tip. > >>>>>>>>>>>> > >>>>>>>>>>>> What is the difference between writing a custom Tomcat > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> authenticator and a custom LoginModule, example, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>> > >> > org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule > >>>>>>>>> ? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>> My understanding is that having custom login modules : > >>>>>>>>>>>> - makes it easy to stack together different > modules, > >>> as > >>>>>>> shown > >>>>>>> > >>>>>>>>>>>> > >>>>>>>>> for ex at [1] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>> - but requires the explicit loading of (JBoss > >>> Security) > >>>>>>>>>>>> > >>>>>>>>> AuthenticationManager (at least when services are POJOs) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>> cheers, Sergey > >>>>>>>>>>>> > >>>>>>>>>>>> [1] > >>>>>>>>>>>> > >>>>>>>>>>>> > >>> > http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS > >>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On 07/13/2010 11:35 AM, Bill Burke wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Remy, Anil, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (I'm cc'ing jboss-dev for archive purposes) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sergey , a new web services/resteasy hire, has done > some > >>>>>>>>>>>>>> > >>>>>>> great > >>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> work > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> around OAuth lately. I'm interested in taking his > stuff > >>> to > >>>>>>> the > >>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> next > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> level and make it consumable in a way JBoss AS users > are > >>>>> used > >>>>>>>>>>>>>> > >>>>>>>>> to > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> configuring security. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Specifically, I'm interested in defining a OAuth > >>>>>>>>>>>>>> login-config/auth-method within web.xml i.e. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> <login-config> > >>>>>>>>>>>>>> <auth-name>OAuth</auth-name> > >>>>>>>>>>>>>> <realm-name>...</realm-name> > >>>>>>>>>>>>>> </login-config> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This would be an initial step, eventually I'd like to > be > >>>>> able > >>>>>>>>>>>>>> > >>>>>>>>> to > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> configure a web app to support multiple authentication > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> mechanisms, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> so > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> that one URL could support both OAuth and traditional > >>>>>>>>>>>>>> > >>>>>>> clients. > >>>>>>> > >>>>>>>>>>>>>> Is JSR 196 the way to do this? Do we support in AS6? > >> Is > >>>>>>> there > >>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>> doco > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>> someplace? (I couldn't find with a search). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Bill > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development